From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= 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 12:04:00 +0000 Message-ID: <6ba1caaf-478c-5ac2-3303-d41fc18dbb09@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3297166914232145773==" List-Id: --===============3297166914232145773== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, thank you for your reply. > Hi, >=20 >> On 25 Jan 2020, at 16:10, Peter M=C3=BCller w= rote: >> >> Hello list, >> >> due to reasons, I currently work on migrating an upstream (Squid) proxy >> machine from HardenedBSD connected via OpenVPN to OpenBSD connected via IP= sec. >> >> 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: >> >>> [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) >> >> Oddly enough, doing the same thing on a machine within the GREEN network w= orks: >> >>> 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 Proxy= 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 beh= aviour's >> root cause. >> >> Connecting to the IPsec machine seems to require a firewall rule like this: >> - source: firewall (any) >> - use NAT: yes, source NAT enabled, new source IP address =3D GREEN >> - destination: IPsec remote machine >> - protocol: any >> >> 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 sou= rce in the route in the IPsec routing table. >=20 > Can you post what is in there? 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] I have not experimented with TRACE flags in iptables yet, but since disabling the IPS does not have any effect on this, I guess that is not the root cause = for once. :-) Thanks, and best regards, Peter M=C3=BCller >=20 >> As far as I am concerned, there are two oddities: >> (a) Even with SNAT enabled, the firewall itself is unable to reliably esta= blish >> 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 confi= gured >> to do so. >> >> 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? >> >> Thanks, and best regards, >> Peter M=C3=BCller >=20 --===============3297166914232145773==--