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

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

[Peter Müller]

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

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.

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

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

[Tom Rymes]

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

Is this in any way related to what causes the issues with SIP and FTP, etc over IPSec unless the ALG is disabled?

> On Jan 25, 2020, at 11:12 AM, 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.
> 
> 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

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

[Peter Müller]

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

Hello Tom,

thanks for your reply.

I have not thought of that yet, but since only the FTP, IRC and TFTP connection
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üller


> Is this in any way related to what causes the issues with SIP and FTP, etc over IPSec unless the ALG is disabled?
> 
>> On Jan 25, 2020, at 11:12 AM, 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.
>>
>> 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

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

[Michael Tremer]

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

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?

> 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

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

[Peter Müller]

[-- 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
> 

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

[Peter Müller]

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

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
>>

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

[Peter Müller]

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

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.

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
>>>

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

[Michael Tremer]

[-- 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
>>>> 

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

[Michael Tremer]

[-- 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