From nobody Mon Oct 10 15:59:50 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 4MmNsb32zmz4fhSb for ; Mon, 10 Oct 2022 16:00:03 +0000 (UTC) (envelope-from andre@andre.adm.br) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4MmNsZ4k6cz4BrB for ; Mon, 10 Oct 2022 16:00:02 +0000 (UTC) (envelope-from andre@andre.adm.br) Received: by mail-qt1-x830.google.com with SMTP id x8so210726qtv.9 for ; Mon, 10 Oct 2022 09:00:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=andre-adm-br.20210112.gappssmtp.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=kbDZ/jaFgmhCKhr6sKgM4x9ztPvSf4aRahCelKqRJA8=; b=LApFXYeWmlD6V4XGjjW2tPhJiytXZENJBClRpGTylgPZ4efHBwiisKYPvLbub/rvFc x2pPvAU1YNgDe5P/3MGTL6MlTnNp2ui7XamsxgJcwZx6oMTQXIOwPd+bLNudGe4+Txl1 fb7Jj9x3WxDO2JP5C5jGyJselM35kONJaGRjuv3YKuw92/CV74ddgA1VPRJwg0hXYk/R ItofxJ/emJMNWEaXR3qIMXr7cwVyTKT9j9ptfzjmNhvlRx5OjQRoNRUmdlSPP7XEehaE Cg5Nbqca8Mu7c9wyPBKvgIVyXmudhXS/vYTHTpNOsfYxlzJdHRL1M+zUJ8jA8Oj0GSFT j2Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=kbDZ/jaFgmhCKhr6sKgM4x9ztPvSf4aRahCelKqRJA8=; b=yK6ok14jB28TEI+A0HLA1vRpzjIn6eEbXyQP6GW9Fq5HIbgx/72J2bocFgWrFeA0L8 Zvgdia7emlP/OdjKuT0LbRvVClcUnqA1G3xefHwJIS9KKtZLf3OeVp3vb9Sio/OHwOKL LQtTHF0XxGAN8YUh3ljjRUxK+KKE6UAEoLhOu1E97gWGsyfXHimUXJCG5uvhQl26pCV9 y97SqOSHX/z4oGH36swmf3sEI4WZrL79syKkk1LAM0Q2ZV+QblgtIeIRv49Wz97I3jtN 2Mi2iGSuvh7OWesI9vzc60oK7QH7vNhqjFx7HcewVbUMBgGD6a0jQwwSRH1obi4pCL/q qZEg== X-Gm-Message-State: ACrzQf24orpe44KMmuv2HA3ssq3Y60zINrEzzRTeY03AkAt4z2KEkJC4 +TD58m5OC5byTdWS5c7yYO+Bkm7Pk875ueRTeO7H9KUJ8b0= X-Google-Smtp-Source: AMsMyM5dMLcRq8//yRlToNvXiyzy2hs+wqcXnJM55eRkHay465dH2hF91r+aYSVWmC99mOk1l5P0dJmbPZHD9iqU26U= X-Received: by 2002:ac8:5c08:0:b0:398:8400:501b with SMTP id i8-20020ac85c08000000b003988400501bmr8332028qti.645.1665417601269; Mon, 10 Oct 2022 09:00:01 -0700 (PDT) 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 References: <1ba3e340-e204-15b0-d395-a942c97c39f5@gmx.at> In-Reply-To: From: =?UTF-8?Q?Andr=C3=A9_S=2E_Almeida?= Date: Mon, 10 Oct 2022 12:59:50 -0300 Message-ID: Subject: Re: PF: nat on ipsec To: pf@freebsd.org Content-Type: multipart/alternative; boundary="00000000000086db7f05eab04043" X-Rspamd-Queue-Id: 4MmNsZ4k6cz4BrB X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=andre-adm-br.20210112.gappssmtp.com header.s=20210112 header.b=LApFXYeW; dmarc=none; spf=pass (mx1.freebsd.org: domain of andre@andre.adm.br designates 2607:f8b0:4864:20::830 as permitted sender) smtp.mailfrom=andre@andre.adm.br X-Spamd-Result: default: False [-2.87 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; R_MIXED_CHARSET(0.62)[subject]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[andre-adm-br.20210112.gappssmtp.com:s=20210112]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; MLMMJ_DEST(0.00)[pf@freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::830:from]; MIME_TRACE(0.00)[0:+,1:+,2:~]; DKIM_TRACE(0.00)[andre-adm-br.20210112.gappssmtp.com:+]; FROM_EQ_ENVFROM(0.00)[]; DMARC_NA(0.00)[andre.adm.br]; RCVD_TLS_LAST(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEFALL_USER(0.00)[andre]; ARC_NA(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[pf@freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: N --00000000000086db7f05eab04043 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Take a look at the sysctl option "net.inet.ipsec.filtertunnel", it needs to be active for NAT to work with IPSec - Andre Em seg., 10 de out. de 2022 =C3=A0s 12:52, Matthew Grooms escreveu: > 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=3Denc&sektion=3D4 > > Good luck! :) > > -Matthew > > -- Andr=C3=A9 S. Almeida http://www.andre.adm.br +55 (48) 98812-3932 --00000000000086db7f05eab04043 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Take a look at the sysctl option "net.inet.ipsec.fil= tertunnel", it needs to be active for NAT to work with IPSec
=

=C2=A0- Andre=C2=A0

Em se= g., 10 de out. de 2022 =C3=A0s 12:52, Matthew Grooms <mgrooms@shrew.net> escreveu:
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 ha= ppens on
>> egress. For traffic to be processed by IPsec, your traffic must ha= ve
>> source and destination addresses that match the appropriate IPsec<= br> >> 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<= br> > 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 i= t
> is an ipsec packet, the host does not translate it but instead forward= s
> 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<= br> > which explicitly use various protocols from /etc/protocols e.g. "= proto
> ipencap" but this does not change the behaviour. It seems like th= e 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?q= uery=3Denc&sektion=3D4

Good luck! :)

-Matthew

--
Andr=C3=A9 S.= Almeida
+55 (48) 98812-3932
--00000000000086db7f05eab04043--