Contributed by Janne Johansson on from the a route to be routed dept.
-current by David Gwynne (
dlg@), likely to be a prominent item for the upcoming OpenBSD 7.4 release.
The main log message:
Some excerpts from the commit messages by
dlg@ explains its purpose and design:
Rather than use ipsec flows (aka, entries in the ipsec security policy database) to decide which traffic should be encapsulated in ipsec and sent to a peer, this tweaks security associations (SAs) so they can refer to a tunnel interface. when traffic is routed over that tunnel interface, an ipsec SA is looked up and used to encapsulate traffic before being sent to the peer on the SA. When traffic is received from a peer using an interface SA, the specified interface is looked up and the packet is handed to it so it looks like packets come out of the tunnel.
sec(4) can be considered equivalent to gif(4) protected by ipsec, and on the wire it actually looks the same. sec(4) exists to better support how security associations for route-based ipsec VPNs are negotiated and to avoid SPD entries for them.
For the full experience, see the series of commits starting with this one.
We look forward to this and several other improvements that will be in the upcoming release.
(Comments are closed)