Sends a DELETE when rekeyed IKE_SAs are deleted. This fixes issues with
peers (e.g. Cisco) that continue to send DPDs on the old SA and then
delete all SAs if no response is received. But since the DELETE could get
dropped this might not fix the issue in all cases.
Also, when terminating an IKE_SA DELETES for all CHILD_SAs are now sent
before sending one for the IKE_SA and destroying it.
Fixes#2090.
If we silently delete the IKE_SA the other peer might still use it even
if only to send DPDs. If we don't answer to DPDs that might result in the
deletion of the new IKE_SA too.
This is the minimum size an IPv6 implementation must support. This makes
it the default for IPv4 too, which presumably is also generally routable
(otherwise, setting this to 0 falls back to the minimum of 576 for IPv4).
The maximum would not get set correctly when a logger is removed and the
first remaining logger in the list (the one with the highest log level) does
e.g. only implement vlog() while there are other loggers that implement log().
This would result in only max_vlevel getting set correctly while max_level
would incorrectly get set to -1 so that log() would not get called for any
of the loggers anymore.
References #574.
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.
This makes the FWD policies in the out direction optional (disabled by
default). They may be enabled (e.g. if conflicting drop policies are
used) via the policies_fwd_out swanctl.conf option.
They are only required if drop policies would otherwise prevent
forwarding traffic. This reduces the number of policies and avoids
conflicts e.g. with SPD hash thresholds.
In case an external thread calls into our code and logs messages, a thread
object is allocated that will never be released. Even if we try to clean
up the object via thread value destructor there is no guarantee that the
thread actually terminates before we check for leaks, which seems to be the
case for the Ada Tasking threads.