The code was written with `child_sa_t::destroy` in mind, which deletes
the inbound SA before the outbound SA. The problem is that the rekeying
code was changed meanwhile so the outbound SA is removed before the
inbound SA in order to avoid traffic loss. That could cause a
use-after-free as the already destroyed item remained in the `isas` list.
This change fixes this so the SAs can be removed in any order. The SPIs
are used as marker for whether a specific direction is installed. It
also fixes an issue in `expire_job()`, which removed the entry from
`osas` without holding the lock.
Fixes: f351d9ef7d ("kernel-wfp: Reference SA/SP sets by SPI and destination, not reqid")
Fixes: 44107cb7b7 ("child-delete: Delay the removal of the inbound SA of rekeyed CHILD_SAs")
The policies reference the provider, so it might not actually get removed
and be left dangling in the WFP system (maybe Windows refcounts it and
still removes it).
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.
Similar to the inbound rules, the ALE filter processes IP-in-IP packets for
outbound tunnel mode traffic. When using an outbound default-drop policy,
Windows does not allow connection initiation without these explicit rules.
When processing inbound tunnel mode packets, Windows decrypts packets and
filters them as IP-in-IP packets. We therefore require an ALE filter that
calls the FWPM_CALLOUT_IPSEC_INBOUND_TUNNEL_ALE_ACCEPT callout to allow them
when using a default-drop policy.
Without these rules, any outbound packet created an ALE state that allows
inbound packets as well. Processing inbound packets without any outbound
traffic fails without these rules.
Having this flag set fixes connections initiated by the Windows host, but
unfortunately does not yet fix incoming connections. Connection state issue?
We still see 0xc00000e2 error events, translating to INTERNAL_ERROR.
This gives us more flexibility than using the intransparent FwpmIPsecTunnelAdd,
and fixes the issues we have seen with trap policies. Forward filters are
still missing, but required for site-to-site tunnels.
Tobias Brunner