From nobody Mon Oct 10 15:51:33 2022 X-Original-To: pf@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4MmNhK3dF1z4fghM for ; Mon, 10 Oct 2022 15:52:01 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mx2.shrew.net (mx2.shrew.net [38.97.5.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4MmNhJ75Q9z49fN for ; Mon, 10 Oct 2022 15:52:00 +0000 (UTC) (envelope-from mgrooms@shrew.net) Received: from mail.shrew.net (mail.shrew.prv [10.24.10.20]) by mx2.shrew.net (8.15.2/8.15.2) with ESMTP id 29AFq0jq008073 for ; Mon, 10 Oct 2022 10:52:00 -0500 (CDT) (envelope-from mgrooms@shrew.net) Received: from [10.22.200.32] (unknown [136.49.68.36]) by mail.shrew.net (Postfix) with ESMTPSA id 02FC8187E20 for ; Mon, 10 Oct 2022 10:51:54 -0500 (CDT) Message-ID: Date: Mon, 10 Oct 2022 10:51:33 -0500 List-Id: Technical discussion and general questions about packet filter (pf) List-Archive: https://lists.freebsd.org/archives/freebsd-pf List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.3.1 Subject: Re: PF: nat on ipsec Content-Language: en-US To: pf@freebsd.org References: <1ba3e340-e204-15b0-d395-a942c97c39f5@gmx.at> From: Matthew Grooms In-Reply-To: <1ba3e340-e204-15b0-d395-a942c97c39f5@gmx.at> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (mx2.shrew.net [10.24.10.11]); Mon, 10 Oct 2022 10:52:00 -0500 (CDT) X-Rspamd-Queue-Id: 4MmNhJ75Q9z49fN X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mgrooms@shrew.net designates 38.97.5.132 as permitted sender) smtp.mailfrom=mgrooms@shrew.net X-Spamd-Result: default: False [-3.27 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.999]; NEURAL_HAM_LONG(-0.97)[-0.970]; R_SPF_ALLOW(-0.20)[+mx:c]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[pf@freebsd.org]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; DMARC_NA(0.00)[shrew.net]; ASN(0.00)[asn:174, ipnet:38.0.0.0/8, country:US]; RCVD_COUNT_THREE(0.00)[3]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[pf@freebsd.org]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: N 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