Date: Mon, 10 Oct 2022 12:59:50 -0300 From: =?UTF-8?Q?Andr=C3=A9_S=2E_Almeida?= <andre@andre.adm.br> To: pf@freebsd.org Subject: Re: PF: nat on ipsec Message-ID: <CADsrzyaXoD9a86q1a3GD=kfUZtscYsgK1uBf0a5v3=e3AqWL2w@mail.gmail.com> In-Reply-To: <bfb2f2d0-8fdb-52b4-1d9b-2baea2a5d983@shrew.net> References: <c35f847b-60cd-fa48-66ae-66c48e3729b1@gmx.at> <e3d77559-8894-5b49-0993-b2988d6fd553@shrew.net> <1ba3e340-e204-15b0-d395-a942c97c39f5@gmx.at> <bfb2f2d0-8fdb-52b4-1d9b-2baea2a5d983@shrew.net>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <mgrooms@shrew.ne= t> 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 <div dir=3D"auto">Take a look at the sysctl option "net.inet.ipsec.fil= tertunnel", it needs to be active for NAT to work with IPSec<br></div>= <div><br></div><div dir=3D"auto">=C2=A0- Andre=C2=A0</div><div dir=3D"auto"= ><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">Em se= g., 10 de out. de 2022 =C3=A0s 12:52, Matthew Grooms <<a href=3D"mailto:= mgrooms@shrew.net">mgrooms@shrew.net</a>> escreveu:<br></div><blockquote= class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc soli= d;padding-left:1ex">On 10/10/22 10:38, infoomatic wrote:<br> > On 10.10.22 17:01, Matthew Grooms wrote:<br> >><br> >> I'm not sure if I understood all the details here, but: NAT ha= ppens on<br> >> egress. For traffic to be processed by IPsec, your traffic must ha= ve<br> >> source and destination addresses that match the appropriate IPsec<= br> >> policy. Waiting until its being sent outbound ( where NAT occurs )= is<br> >> usually too late.<br> >><br> > thanks for your response. The source and destination addresses in the<= br> > configuration are OK. Every non-ipsec packet coming from opnsense is<b= r> > translated as in the pf.conf on the host. The problem is: as soon as i= t<br> > is an ipsec packet, the host does not translate it but instead forward= s<br> > the packet with the original private ip through the physical interface= <br> > with the public ip address (which of course is prohibited by a rule<br= > > 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<br> > ipencap" but this does not change the behaviour. It seems like th= e host<br> > realizes it is an ipsec packet and just refuses to nat that packet.<br= > ><br> ><br> > Out of curiosity I ordered another hardware host where I installed<br> > Linux, created a VM with opnsense (with the same config, the only<br> > adaption was the public ip-address in the ipsec configuration) and a<b= r> > client on opnsense's LAN interface. I used iptables and it worked = as<br> > expected ... every packet on egress is translated to the outgoing ip<b= r> > address.<br> ><br> <br> IPsec traffic flow is complicated. Have a look at enc. It's been <br> instrumental in helping me fix this class of issue in several instances. <b= r> YMMV.<br> <br> <a href=3D"https://www.freebsd.org/cgi/man.cgi?query=3Denc&sektion=3D4"= rel=3D"noreferrer" target=3D"_blank">https://www.freebsd.org/cgi/man.cgi?q= uery=3Denc&sektion=3D4</a><br> <br> Good luck! :)<br> <br> -Matthew<br> <br> </blockquote></div></div>-- <br><div dir=3D"ltr" class=3D"gmail_signature" = data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div>Andr=C3=A9 S.= Almeida</div><div><a href=3D"http://www.andre.adm.br" target=3D"_blank">ht= tp://www.andre.adm.br</a></div><div>+55 (48) 98812-3932</div></div></div></= div> --00000000000086db7f05eab04043--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CADsrzyaXoD9a86q1a3GD=kfUZtscYsgK1uBf0a5v3=e3AqWL2w>