From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter =?utf-8?q?M=C3=BCller?= <peter.mueller@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 16:22:00 +0000
Message-ID: <971f9061-a035-c621-c4ed-0fd1a0994efa@ipfire.org>
In-Reply-To: <6ba1caaf-478c-5ac2-3303-d41fc18dbb09@ipfire.org>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============0680597200299484612=="
List-Id: <development.lists.ipfire.org>

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

Hello Michael,

> Hello Michael,
>=20
> thank you for your reply.
>=20
>> Hi,
>>
>>> On 25 Jan 2020, at 16:10, Peter M=C3=BCller <peter.mueller(a)ipfire.org> =
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 I=
Psec.
>>>
>>> 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 =
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 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.
>>>
>>> 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
>>>
>>> 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 so=
urce in the route in the IPsec routing table.

Unfortunately, it is. If the NAT rule is not present, traffic to the remote I=
Psec
IP address is emitted to the internet directly and dropped a few hops later by
my ISP. :-(

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 destinat=
ions
from a machine within GREEN works fine and is passed through the tunnel.

Thanks, and best regards,
Peter M=C3=BCller

>>
>> 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]
>=20
> 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
>>
>>> 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.
>>>
>>> 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
>>

--===============0680597200299484612==--