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