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:37:36 +0000 Message-ID: In-Reply-To: <63121aa9-d545-2e14-0980-7771c6811ad2@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============7584172335391999375==" List-Id: --===============7584172335391999375== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Well, we have not really figured out if this is a bug of misconfiguration, ye= t. > On 26 Jan 2020, at 17:14, Peter M=C3=BCller wr= ote: >=20 > Hello *, >=20 > in order not to lose track on this and keep discussions clearly, this is now > filed as #12280 (https://bugzilla.ipfire.org/show_bug.cgi?id=3D12280), while > the "IPsec traffic is emitted to the internet directly" was already filed as > #12257 (https://bugzilla.ipfire.org/show_bug.cgi?id=3D12257), but I did not > expect this to be that worse. And for the latter one you wanted to submit a patch. I have made the necessar= y changes on your system already. >=20 > Thanks, and best regards, > Peter M=C3=BCller >=20 >> Hello Michael, >>=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= IPsec. >>>>>=20 >>>>> The latter one seems to work since the connection is stable and SSH usa= ge >>>>> over the tunnel is possible. However, using the remote Squid proxy as an >>>>> upstream proxy (refer to corresponding setting in proxy.cgi) is impossi= ble >>>>> 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 networ= k 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 Pr= oxy 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 rem= ote >>>>> IPsec one, which makes me writing this mail as I am not sure about the = behaviour's >>>>> root cause. >>>>>=20 >>>>> Connecting to the IPsec machine seems to require a firewall rule like t= his: >>>>> - 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 v= ia >>>>> 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 = source in the route in the IPsec routing table. >>=20 >> Unfortunately, it is. If the NAT rule is not present, traffic to the remot= e IPsec >> IP address is emitted to the internet directly and dropped a few hops late= r by >> my ISP. :-( >>=20 >> This behaviour is reproducible for _all_ IPsec N2N connections running her= e, and >> as far as I am concerned, it should not happen. ping to remote IPsec desti= nations >> from a machine within GREEN works fine and is passed through the tunnel. >>=20 >> Thanks, and best regards, >> Peter M=C3=BCller >>=20 >>>>=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 addre= ss of the GREEN interface] >>>=20 >>> I have not experimented with TRACE flags in iptables yet, but since disab= ling >>> the IPS does not have any effect on this, I guess that is not the root ca= use 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 e= stablish >>>>> 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 co= nfigured >>>>> 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 >>>>=20 --===============7584172335391999375==--