Fixes a problem installing policies with source traffic selectors that do
not contain/match any of the local addresses.
When installing a route for a source TS that does contain one or more
local addresses, a preferred source address should be set in the route
(analogous to the `src` option in `ip route add`). This address is used
when the host itself sends traffic via that route (in contrast to
forwarding it).
When the source TS does not encompass any of the local addresses, the
host is not allowed to send traffic via this route and does not need to
set the preferred source address. However, the code would just return a
failure because it could not find a matching local address. This commit
changes this so routes without preferred source IP are installed to
allow non-local traffic to get forwarded via TUN device.
Closesstrongswan/strongswan#1766
This is currently only supported on Linux and with the appropriate
permissions.
Since it's experimental, it's disabled by default.
The log messages for each sent and received ESP message are logged in NET
like the ones in the socket-default plugin for UDP-encapsulated messages.
Currently supported by libipsec and PF_KEY on macOS (FreeBSD, like Linux,
reports the time the SA was first used in sadb_lifetime_usetime - it also
triggers rekeyings based on that, which Linux doesn't, it also triggers
them if an SA is never used).
Enables us to ignore any future kernel features for routes unless
we actually need to consider them for the source IP routes.
Also enables us to actually really skip IPsec processing for those networks
(because even the routes don't touch those packets). It's more what
users expect.
Co-authored-by: Tobias Brunner <[email protected]>
The current "inbound" flag is used for two purposes: To define the actual
direction of the SA, but also to determine the operation used for SA
installation. If an SPI has been allocated, an update operation is required
instead of an add.
While the inbound flag normally defines the kind of operation required, this
is not necessarily true in all cases. On the HA passive node, we install inbound
SAs without prior SPI allocation.
While we can handle the first selector only in BEET mode in kernel-netlink,
passing the full list gives the backend more flexibility how to handle this
information.
The reqid is not strictly required, as we set the reqid with the update
call when installing the negotiated SA.
If we don't need a reqid at this stage, we can later allocate the reqid in
the kernel backend once the SA parameters have been fully negotaited. This
allows us to assign the same reqid for the same selectors to avoid conflicts
on backends this is necessary.
This actually broke rekeying due to the DROP policies that are
temporarily added, which broke the refcount as the ignored policies
were not ignored in del_policy() (the type is not known there).
Setting the fwmark options for the kernel-netlink and socket-default
plugins allow this kind of setup.
It is probably required to set net.ipv4.conf.all.rp_filter to 2 to make
it work.
The routes direct traffic matching the remote traffic selector to the
TUN device.
If the remote traffic selector includes the IKE peer a very specific route
is installed to allow IKE traffic.
Tobias Brunner