Re: firewall oddities when accessing services at the far side of an IPsec N2N connection

[Michael Tremer <michael.tremer@ipfire.org>]

[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]

Hi,

> On 26 Jan 2020, at 12:04, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello Michael,
> 
> thank you for your reply.
> 
>> Hi,
>> 
>>> On 25 Jan 2020, at 16:10, Peter Müller <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 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 impossible
>>> as responses are not answered from the remote side:
>>> 
>>>> [root(a)maverick ~]# export http_proxy="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... 
>>>> (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="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 … verbunden.
>>>> Proxy-Anforderung gesendet, auf Antwort wird gewartet … 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 behaviour'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 = 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 source in the route in the IPsec routing table.
>> 
>> 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 address of the GREEN interface]

And 10.xxx.xxx.1 is not the IP address you were expecting on the outgoing packet?

> I have not experimented with TRACE flags in iptables yet, but since disabling
> the IPS does not have any effect on this, I guess that is not the root cause for once. :-)
> 
> Thanks, and best regards,
> Peter Müller
> 
>> 
>>> As far as I am concerned, there are two oddities:
>>> (a) Even with SNAT enabled, the firewall itself is unable to reliably establish
>>> 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 configured
>>> 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üller