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.
Martin Willi