While trap and regular policies now often look the same (mainly because
reqids are kept constant) trap policies still need to have a lower priority
than regular policies to handle unroute/route correctly if e.g. IPComp
is used or the mode changes. But if we use a completely different
priority range that's lower than that of regular policies it is not possible
to install overlapping trap policies. By differentiating trap from
regular policies via the priority's LSB this issue is avoided while
still maintaining the proper ordering of trap and regular policies.
Fixes#1243.
By default, the kernel incorrectly uses an 8 byte alignment, which is
mandatory for IPv6 but prohibited for IPv4. For many algorithms this
doesn't matter but that's not the case for HMAC_SHA2_256_128.
Since 2.6.39 the kernel can be explicitly configured to use a 4 byte
alignment.
The kernel will apply the mask to the mark on the packet and then
compare it to the configured mark. So to match only unmarked packets we
have to be able to set 0/0xffffffff.
If the number of flows over a gateway exceeds the flow cache size of the Linux
kernel, policy lookup gets very expensive. Policies covering more than a single
address don't get hash-indexed by default, which results in wasting most of
the cycles in xfrm_policy_lookup_bytype() and its xfrm_policy_match() use.
Starting with several hundred policies the overhead gets inacceptable.
Starting with Linux 3.18, Linux can hash the first n-bit of a policy subnet
to perform indexed lookup. With correctly chosen netbits, this can completely
eliminate the performance impact of policy lookups, freeing the resources
for ESP crypto.
WARNING: Due to a bug in kernels 3.19 through 4.7, the kernel crashes with a
NULL pointer dereference if a socket policy is installed while hash thresholds
are changed. And because the hashtable rebuild triggered by the threshold
change that causes this is scheduled it might also happen if the socket
policies are seemingly installed after setting the thresholds.
The fix for this bug - 6916fb3b10b3 ("xfrm: Ignore socket policies when
rebuilding hash tables") - is included since 4.8 (and might get backported).
As a workaround `charon.plugins.kernel-netlink.port_bypass` may be enabled
to replace the socket policies that allow IKE traffic with port specific
bypass policies.
We don't need them for drop policies and they might even mess with other
routes we install. Routes for policies with protocol/ports in the
selector will always be too broad and might conflict with other routes
we install.
Using the source address to determine the interface is not correct for
net-to-net shunts between two interfaces on which the host has IP addresses
for each subnet.
Other threads are free to add/update/delete other policies.
This tries to prevent race conditions caused by releasing the mutex while
sending messages to the kernel. For instance, if break-before-make
reauthentication is used and one thread on the responder is delayed in
deleting the policies that another thread is concurrently adding for the
new SA. This could have resulted in no policies being installed
eventually.
Fixes#1400.
This allows using manual priorities for traps, which have a lower
base priority than the resulting IPsec policies. This could otherwise
be problematic if, for example, swanctl --install/uninstall is used while
an SA is established combined with e.g. IPComp, where the trap policy does
not look the same as the IPsec policy (which is now otherwise often the case
as the reqids stay the same).
It also orders policies by selector size if manual priorities are configured
and narrowing occurs.
The kernel policy now considers src and dst port masks as well as
restictions to a given network interface. The base priority is
100'000 for passthrough shunts, 200'000 for IPsec policies,
300'000 for IPsec policy traps and 400'000 for fallback drop shunts.
The values 1..30'000 can be used for manually set priorities.
This allows two CHILD_SAs with reversed subnets to install two FWD
policies each. Since the outbound policy won't have a reqid set we will
end up with the two inbound FWD policies installed in the kernel, with
the correct templates to allow decrypted traffic.
We can't set a template on the outbound FWD policy (or we'd have to make
it optional). Because if the traffic does not come from another (matching)
IPsec tunnel it would get dropped due to the template mismatch.
This allows us to install more than one FWD policy. We already do this
in the kernel-pfkey plugin (there the original reason was that not all
kernels support FWD policies).
Tobias Brunner