Date: Sun, 26 Sep 2021 13:12:05 +1000 From: Peter Jeremy <peter@rulingia.com> To: "Andrey V. Elsukov" <bu7cher@yandex.ru> Cc: Eugene Grosbein <eugen@grosbein.net>, freebsd-net@freebsd.org, "Alexander V. Chernikov" <melifaro@freebsd.org> Subject: Re: IPSEC problems with pf Message-ID: <YU/lBWIQMNGQebwq@server.rulingia.com> In-Reply-To: <88c23447-4733-80a2-cb59-f0720b4b836c@yandex.ru> References: <YU5ZKsBQ73UJ71r2@server.rulingia.com> <63369d6b-23f3-3d4e-4ff8-dd068c894564@grosbein.net> <88c23447-4733-80a2-cb59-f0720b4b836c@yandex.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
--WkinrWASy6+4Arsx Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Thanks for all the responses, they provided useful pointers. I've discovered that the problem was at least partially my misunderstanding of the way iked works (and my failure to mention some important differences between my working and non-working configurations). Note that I'm trying to configure IPSEC in transport, not tunnel mode. I think some of the responses assumed that I was using tunnel mode. In the following: Host ---- firewall =3D=3D=3D=3D(internet)=3D=3D=3D=3D VPS '=3D=3D' indicates the path I want as an IPSEC (esp) transport - I expect that VPS thinks it's talking to "firewall" and is unaware of the (NAT'd) connection between firewall and Host. My firewall is running 12.2, whereas the other systems I was testing with were 13 or 14. 12.x doesn't support extended sequence numbers. I had assumed the message: iked[3516]: pfkey_sa: kernel has no support for extended sequence numbers (= ESN) was a warning and it would negotiate down. I've worked out that iked doesn't actually negotiate but instead initiates a SA based solely on its local configuration so that's actually a fatal error that prevented the SA being setup in one direction. Once I added "childsa noesn" at the remote (13.x) end, I got bidirectional IPSEC transport setup. On 2021-Sep-25 16:06:55 +0300, "Andrey V. Elsukov" <bu7cher@yandex.ru> wrot= e: >25.09.2021 03:31, Eugene Grosbein =D0=BF=D0=B8=D1=88=D0=B5=D1=82: >> I know three main reasons that may prevent firewall+IPSec from working a= s expected: >>=20 >> 1) for incoming packets: kernel could drop incoming packet withing ipsec= code >> incrementing one of counters shown with "netstat -sp ipsec" command, >> so you should check it out first; And "netstat -sp esp". I also found /usr/src/tools/tools/crypto/ipsecstats= =2Ec dumps all the ipsec-related counters from the kernel. >> 2) for both outgoing and incoming packets there could be processing orde= r problem: >> packets processed first by pfil(9) framework (so pf/ipfw have a chance t= o do NAT etc.) >> and only then sent to ipsec(4) to transform (in FreeBSD 11 at least), no= t vice versa. > >AFAIK, pf does not send packets to IPsec processing after NAT. You need >to make translation after IPsec processing using the if_enc interface. I'm reasonably confident that this is my remaining problem and am working on better understanding the interactions between IPSEC and pfil(9). >> 3) also read if_enc(4) manual page to make familiar with net.enc.out.* a= nd net.enc.in.* sysctl family, >> as it may affect, too. If you do not use enc(4) pseudo-interface, make s= ure you changed defaults to: >>=20 >> net.enc.in.ipsec_filter_mask=3D0 >> net.enc.out.ipsec_filter_mask=3D0 I wasn't using enc(4) and don't have it loaded. enc(4) reads like it is intended for ESP tunnel mode, rather than transport mode. On the offchance that it would help, I tried loading it and experimenteng with the various filter mask options but it didn't help. >Another important variable that needs an attention is >net.inet.ipsec.filtertunnel I discovered that but, unfortunately, it seems to only apply to inbound (from the Internet) packets. At this point: * I can exchange encrypted packets locally between firewall and VPS * Encrypted packets sent from VPS will arrive at Host (once net.inet.ipsec.filtertunnel is set). * Packets sent from Host to VPS get sent unencrypted over the Internet. I'm confident that the last point is because the IPSEC processing preceeds the pfil processing on outbound packets, so they aren't seen as eligible because IPSEC is seeing the internal, rather than external, address. --=20 Peter Jeremy --WkinrWASy6+4Arsx Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEE7rKYbDBnHnTmXCJ+FqWXoOSiCzQFAmFP5QBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEVF QjI5ODZDMzA2NzFFNzRFNjVDMjI3RTE2QTU5N0EwRTRBMjBCMzQACgkQFqWXoOSi CzRUOxAAj8lW+FgF+DDIeu2bx9FCT6RDkSqEAQmCQC+QakqofGgRCpQ/90V68Ltv 2psL7M1sJl+k2Cc7YdUZoEkN74itgIGi9mkb27qeKVAZdnk6XyZXUW0uVXN3G8zJ ountU5Vp9A/sKkT4AQbFalEIqwLfr26b3n4JkWt+BUUvjBYV5vlbbZUVG1OE0VV3 o4SJxe7H76Q9vtg655iUc7iecVjEDSS6VVbecLHW4+j90v1o7X8wHz9mT1fI0oXF ua8OvBcNSyn9lInbehxVV6bQwbRiGO1w175wMAk1eNsdGvf5BTtKuz6uxAnmUMiR QKyhijke16w2TvclMDS/tN+wuyAYs7FVY2TiWYuoKHgIFsky3SrVPbsO2Wzv3QyH U48U1BuRTyCmKjZDuRio+7/uNs6ToMQBn2K66LKplXaJH3drCsgAzJPMIkYk03MA 4QojEviy7SioVl0JRQzjVH4rd3hPco7wY7Zp6sIiw12qy5ZFD3Yzm/oFmMZZa2/W usK67uI8qobBQgi7Lkr+tZuG6BbjI1qG+Fz9wzBujv/0lUVnT72faPvOr5eFNr0h 2z+i0oGhUJeMSdC1EwPXX+Ub9vwofQgEZCCt8YZ7oF/xjrwjgds8SkapbvkGC0nx AYrHUfQVnMivJVdFg5tAsfW9W8N9W6Vw9NrqrOCKEcE+lWGlZoI= =GM0+ -----END PGP SIGNATURE----- --WkinrWASy6+4Arsx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YU/lBWIQMNGQebwq>