From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael Tremer To: development@lists.ipfire.org Subject: Re: firewall oddities when accessing services at the far side of an IPsec N2N connection Date: Sun, 26 Jan 2020 20:36:33 +0000 Message-ID: In-Reply-To: <6ba1caaf-478c-5ac2-3303-d41fc18dbb09@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============4281734769189313897==" List-Id: --===============4281734769189313897== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, > On 26 Jan 2020, at 12:04, Peter M=C3=BCller wr= ote: >=20 > Hello Michael, >=20 > thank you for your reply. >=20 >> Hi, >>=20 >>> On 25 Jan 2020, at 16:10, Peter M=C3=BCller = wrote: >>>=20 >>> Hello list, >>>=20 >>> due to reasons, I currently work on migrating an upstream (Squid) proxy >>> machine from HardenedBSD connected via OpenVPN to OpenBSD connected via I= Psec. >>>=20 >>> The latter one seems to work since the connection is stable and SSH usage >>> over the tunnel is possible. However, using the remote Squid proxy as an >>> upstream proxy (refer to corresponding setting in proxy.cgi) is impossible >>> as responses are not answered from the remote side: >>>=20 >>>> [root(a)maverick ~]# export http_proxy=3D"http://10.xxx.xxx.2:3128/" >>>> [root(a)maverick ~]# wget -vv example.com >>>> --2020-01-25 16:58:00-- http://example.com/ >>>> Connecting to 10.xxx.xxx.2:3128... connected. >>>> Proxy request sent, awaiting response...=20 >>>> (wget stalls and eventually runs in a timeout) >>>=20 >>> Oddly enough, doing the same thing on a machine within the GREEN network = works: >>>=20 >>>> user(a)machine:~> export http_proxy=3D"http://10.xxx.xxx.2:3128/" >>>> user(a)machine:~> wget -vv heise.de >>>> --2020-01-25 16:59:26-- http://heise.de/ >>>> Verbindungsaufbau zu 10.xxx.xxx.2:3128 =E2=80=A6 verbunden. >>>> Proxy-Anforderung gesendet, auf Antwort wird gewartet =E2=80=A6 407 Prox= y Authentication Required >>>> 2020-01-25 16:59:26 FEHLER 407: Proxy Authentication Required. >>> However, a SSH login _is_ possible from the firewall machine to the remote >>> IPsec one, which makes me writing this mail as I am not sure about the be= haviour's >>> root cause. >>>=20 >>> Connecting to the IPsec machine seems to require a firewall rule like thi= s: >>> - source: firewall (any) >>> - use NAT: yes, source NAT enabled, new source IP address =3D GREEN >>> - destination: IPsec remote machine >>> - protocol: any >>>=20 >>> If source NAT is omitted, accessing the IPsec machine is not possible via >>> any given way (ping, SSH, Squid, ...). However, _if_ SNAT is enabled, it >>> also affects connections made from the machine within the GREEN network. >>=20 >> The NAT rule should not be necessary because we are setting the correct so= urce in the route in the IPsec routing table. >>=20 >> Can you post what is in there? >=20 > Here you are: >> [root(a)maverick ~]# ip route show table 220 >> [3 lines regarding other IPsec connections redacted] >> 10.xxx.xxx.2 dev ppp0 proto static scope link src 10.xxx.xxx.1 [IP address= of the GREEN interface] And 10.xxx.xxx.1 is not the IP address you were expecting on the outgoing pac= ket? > I have not experimented with TRACE flags in iptables yet, but since disabli= ng > the IPS does not have any effect on this, I guess that is not the root caus= e for once. :-) >=20 > Thanks, and best regards, > Peter M=C3=BCller >=20 >>=20 >>> As far as I am concerned, there are two oddities: >>> (a) Even with SNAT enabled, the firewall itself is unable to reliably est= ablish >>> a connection to an remote IPsec destination. >>> (b) If SNAT is enabled for outgoing traffic generated by the firewall, it >>> also seems to affect traffic from GREEN/... sources, while it is not conf= igured >>> to do so. >>>=20 >>> Is there anybody who got remote upstream proxies via IPsec working? >>> Are (a) and (b) bugs? If not: What shall I do to work around these? >>>=20 >>> Thanks, and best regards, >>> Peter M=C3=BCller --===============4281734769189313897==--