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

["Peter Müller" <peter.mueller@ipfire.org>]

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

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]

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
>