From mboxrd@z Thu Jan  1 00:00:00 1970
From: Michael Tremer <michael.tremer@ipfire.org>
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 09:58:17 +0000
Message-ID: <C6D51141-7157-4048-8F8B-C1CD8F4C471E@ipfire.org>
In-Reply-To: <ca856828-2d12-acb4-2813-4d08f4a0c012@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5801956206754950474=="
List-Id: <development.lists.ipfire.org>

--===============5801956206754950474==
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

Hi,

> On 25 Jan 2020, at 16:10, Peter M=C3=BCller <peter.mueller(a)ipfire.org> wr=
ote:
>=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 IPs=
ec.
>=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 wo=
rks:
>=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 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 beha=
viour's
> root cause.
>=20
> 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
>=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.

The NAT rule should not be necessary because we are setting the correct sourc=
e in the route in the IPsec routing table.

Can you post what is in there?

> As far as I am concerned, there are two oddities:
> (a) Even with SNAT enabled, the firewall itself is unable to reliably estab=
lish
> 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 config=
ured
> 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


--===============5801956206754950474==--