Date: Tue, 11 Oct 2022 13:08:57 +0200 From: infoomatic <infoomatic@gmx.at> To: pf@freebsd.org Subject: Re: PF: nat on ipsec Message-ID: <eaeca1fd-f473-072d-36fa-29923ed109a9@gmx.at> In-Reply-To: <CADsrzyaXoD9a86q1a3GD=kfUZtscYsgK1uBf0a5v3=e3AqWL2w@mail.gmail.com> 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> <CADsrzyaXoD9a86q1a3GD=kfUZtscYsgK1uBf0a5v3=e3AqWL2w@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------0glmfJ3re0Wcpg5eEbGFHgDL Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable > 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 > <https://www.freebsd.org/cgi/man.cgi?query=3Denc&sektion=3D4>; > I have no clue why the host should try to do anything with the packets except for changing source and destination address (NAT). The tunnel is setup between AWS and the VM on the host. The ssh connection from AWS to a client "behind" opnsense works. However, as soon as I try to make a ssh connection from the jail ("behind" opnsense) to AWS, the packets from my local vpn endpoint (opnsense VM) do not get NATed on the host. The host just tries to forward those UDP Port 4500 packets with the private ipv4 address of the opnsense VM as source on the egress interface with the public interface. This of course should not happen. Routing problems can be ruled out, the exact same configuration is working on a Linux host hosting the same opnsense VM. A simple |sysctl net.ipv4.ip_forward=3D1 && iptables -t nat -A POSTROUTING --source 192.168.251.100 -j SNAT --to-source $public_vpn_ip| did the trick. There is a strange problem here, maybe it is not pf related, maybe something in the stack interferes with those packets. Anyone knows/could guess if this works with ipfw instead? --------------0glmfJ3re0Wcpg5eEbGFHgDL Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> </head> <body text="#000000" bgcolor="#FFFFFF"> <br> <blockquote type="cite" cite="mid:CADsrzyaXoD9a86q1a3GD=kfUZtscYsgK1uBf0a5v3=e3AqWL2w@mail.gmail.com"> <div dir="auto"> <div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> 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. <br> YMMV.<br> <br> <a href="https://www.freebsd.org/cgi/man.cgi?query=enc&sektion=4" rel="noreferrer" target="_blank" moz-do-not-send="true">https://www.freebsd.org/cgi/man.cgi?query=enc&sektion=4</a><br>; </blockquote> </div> </div> </blockquote> <p><br> </p> <p>I have no clue why the host should try to do anything with the packets except for changing source and destination address (NAT). <br> </p> <p>The tunnel is setup between AWS and the VM on the host. The ssh connection from AWS to a client "behind" opnsense works.</p> <p>However, as soon as I try to make a ssh connection from the jail ("behind" opnsense) to AWS, the packets from my local vpn endpoint (opnsense VM) do not get NATed on the host. The host just tries to forward those UDP Port 4500 packets with the private ipv4 address of the opnsense VM as source on the egress interface with the public interface. This of course should not happen. Routing problems can be ruled out, the exact same configuration is working on a Linux host hosting the same opnsense VM. A simple</p> <p><code style="background-color: #dee3e7; padding: .2px; margin: .1em; display: inline-block;">sysctl net.ipv4.ip_forward=1 && iptables -t nat -A POSTROUTING --source 192.168.251.100 -j SNAT --to-source $public_vpn_ip</code><br> </p> <p> did the trick. There is a strange problem here, maybe it is not pf related, maybe something in the stack interferes with those packets.</p> <p>Anyone knows/could guess if this works with ipfw instead?<br> </p> <p></p> </body> </html> --------------0glmfJ3re0Wcpg5eEbGFHgDL--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?eaeca1fd-f473-072d-36fa-29923ed109a9>