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 12:01:00 +0000
Message-ID: <9e872104-eeb0-dff7-7d34-4a9863a5793d@ipfire.org>
In-Reply-To: <7599AEC0-F1FB-4CC3-8A3D-3EFB5304B878@rymes.com>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="===============5827701815273252390=="
List-Id: <development.lists.ipfire.org>

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

Hello Tom,

thanks for your reply.

I have not thought of that yet, but since only the FTP, IRC and TFTP connecti=
on
tracking helpers are enabled, and HTTP has nothing to do with all of these, I
guess this issue is not related. :-)

Disabling the IPS does not change the behaviour, too.

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


> Is this in any way related to what causes the issues with SIP and FTP, etc =
over IPSec unless the ALG is disabled?
>=20
>> On Jan 25, 2020, at 11:12 AM, Peter M=C3=BCller <peter.mueller(a)ipfire.or=
g> 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 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.
>>
>> 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

--===============5827701815273252390==--