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 17:14:00 +0000 Message-ID: <63121aa9-d545-2e14-0980-7771c6811ad2@ipfire.org> In-Reply-To: <971f9061-a035-c621-c4ed-0fd1a0994efa@ipfire.org> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============5444419603972314296==" List-Id: --===============5444419603972314296== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello *, 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. Thanks, and best regards, Peter M=C3=BCller > Hello Michael, >=20 >> Hello Michael, >> >> thank you for your reply. >> >>> Hi, >>> >>>> On 25 Jan 2020, at 16:10, Peter M=C3=BCller = wrote: >>>> >>>> Hello list, >>>> >>>> due to reasons, I currently work on migrating an upstream (Squid) proxy >>>> machine from HardenedBSD connected via OpenVPN to OpenBSD connected via = IPsec. >>>> >>>> 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 impossib= le >>>> 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= works: >>>> >>>>> 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 Pro= xy 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 remo= te >>>> IPsec one, which makes me writing this mail as I am not sure about the b= ehaviour's >>>> root cause. >>>> >>>> Connecting to the IPsec machine seems to require a firewall rule like th= is: >>>> - 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. >>> >>> The NAT rule should not be necessary because we are setting the correct s= ource in the route in the IPsec routing table. >=20 > Unfortunately, it is. If the NAT rule is not present, traffic to the remote= IPsec > IP address is emitted to the internet directly and dropped a few hops later= by > my ISP. :-( >=20 > This behaviour is reproducible for _all_ IPsec N2N connections running here= , and > as far as I am concerned, it should not happen. ping to remote IPsec destin= ations > from a machine within GREEN works fine and is passed through the tunnel. >=20 > Thanks, and best regards, > Peter M=C3=BCller >=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 addres= s of the GREEN interface] >> >> I have not experimented with TRACE flags in iptables yet, but since disabl= ing >> the IPS does not have any effect on this, I guess that is not the root cau= se for once. :-) >> >> Thanks, and best regards, >> Peter M=C3=BCller >> >>> >>>> As far as I am concerned, there are two oddities: >>>> (a) Even with SNAT enabled, the firewall itself is unable to reliably es= tablish >>>> 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 con= figured >>>> 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 >>> --===============5444419603972314296==--