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: 4728 bytes --]

Well, we have not really figured out if this is a bug of misconfiguration, yet.

> On 26 Jan 2020, at 17:14, Peter Müller <peter.mueller(a)ipfire.org> wrote:
> 
> Hello *,
> 
> in order not to lose track on this and keep discussions clearly, this is now
> filed as #12280 (https://bugzilla.ipfire.org/show_bug.cgi?id=12280), while
> the "IPsec traffic is emitted to the internet directly" was already filed as
> #12257 (https://bugzilla.ipfire.org/show_bug.cgi?id=12257), but I did not
> expect this to be that worse.

And for the latter one you wanted to submit a patch. I have made the necessary changes on your system already.

> 
> Thanks, and best regards,
> Peter Müller
> 
>> Hello Michael,
>> 
>>> 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.
>> 
>> Unfortunately, it is. If the NAT rule is not present, traffic to the remote IPsec
>> 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 destinations
>> from a machine within GREEN works fine and is passed through the tunnel.
>> 
>> Thanks, and best regards,
>> Peter Müller
>> 
>>>> 
>>>> 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
>>>>