Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 10 Oct 2022 10:51:33 -0500
From:      Matthew Grooms <mgrooms@shrew.net>
To:        pf@freebsd.org
Subject:   Re: PF: nat on ipsec
Message-ID:  <bfb2f2d0-8fdb-52b4-1d9b-2baea2a5d983@shrew.net>
In-Reply-To: <1ba3e340-e204-15b0-d395-a942c97c39f5@gmx.at>
References:  <c35f847b-60cd-fa48-66ae-66c48e3729b1@gmx.at> <e3d77559-8894-5b49-0993-b2988d6fd553@shrew.net> <1ba3e340-e204-15b0-d395-a942c97c39f5@gmx.at>

next in thread | previous in thread | raw e-mail | index | archive | help
On 10/10/22 10:38, infoomatic wrote:
> On 10.10.22 17:01, Matthew Grooms wrote:
>>
>> I'm not sure if I understood all the details here, but: NAT happens on
>> egress. For traffic to be processed by IPsec, your traffic must have
>> source and destination addresses that match the appropriate IPsec
>> policy. Waiting until its being sent outbound ( where NAT occurs ) is
>> usually too late.
>>
> thanks for your response. The source and destination addresses in the
> configuration are OK. Every non-ipsec packet coming from opnsense is
> translated as in the pf.conf on the host. The problem is: as soon as it
> is an ipsec packet, the host does not translate it but instead forwards
> the packet with the original private ip through the physical interface
> with the public ip address (which of course is prohibited by a rule
> further down in pf.conf). I have tried to add various nat + rdr rules
> which explicitly use various protocols from /etc/protocols e.g. "proto
> ipencap" but this does not change the behaviour. It seems like the host
> realizes it is an ipsec packet and just refuses to nat that packet.
>
>
> Out of curiosity I ordered another hardware host where I installed
> Linux, created a VM with opnsense (with the same config, the only
> adaption was the public ip-address in the ipsec configuration) and a
> client on opnsense's LAN interface. I used iptables and it worked as
> expected ... every packet on egress is translated to the outgoing ip
> address.
>

IPsec traffic flow is complicated. Have a look at enc. It's been 
instrumental in helping me fix this class of issue in several instances. 
YMMV.

https://www.freebsd.org/cgi/man.cgi?query=enc&sektion=4

Good luck! :)

-Matthew



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bfb2f2d0-8fdb-52b4-1d9b-2baea2a5d983>