Date: Mon, 10 Oct 2022 17:38:47 +0200 From: infoomatic <infoomatic@gmx.at> To: pf@freebsd.org Subject: Re: PF: nat on ipsec Message-ID: <1ba3e340-e204-15b0-d395-a942c97c39f5@gmx.at> In-Reply-To: <e3d77559-8894-5b49-0993-b2988d6fd553@shrew.net> References: <c35f847b-60cd-fa48-66ae-66c48e3729b1@gmx.at> <e3d77559-8894-5b49-0993-b2988d6fd553@shrew.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Best regards, Robert
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1ba3e340-e204-15b0-d395-a942c97c39f5>