By using the total retransmit timeout, modifications of timeout settings
automatically reflect on the value of xfrm_acq_expires. If set, the
value of xfrm_acq_expires configured by the user takes precedence over
the calculated value.
On Linux, setting the source address is insufficient to force a packet to be
sent over a certain path. The kernel uses the best route to select the outgoing
interface, even if we set a source address of a lower priority interface. This
is not only true for interfaces attaching to the same subnet, but also for
unrelated interfaces; the kernel (at least on 4.7) sends out the packet on
whatever interface it sees fit, even if that network does not expect packets
from the source address we force to.
When a better interface becomes available, strongSwan sends its MOBIKE address
list update using the old source address. But the kernel sends that packet over
the new best interface. If that network drops packets having the unexpected
source address from the old path, the MOBIKE update fails and the SA finally
times out.
To enforce a specific interface for our packet, we explicitly set the interface
index from the interface where the source address is installed. According to
ip(7), this overrules the specified source address to the primary interface
address. As this could have side effects to installations using multiple
addresses on a single interface, we disable the option by default for now.
This also allows using IPv6 link-local addresses, which won't work if
the outbound interface is not set explicitly.
The tpm plugin can be used to derive true random numbers from a
TPM 2.0 device. The get_random method must be explicitly enabled
in strongswan.conf with the plugin.tpm.use_rng = yes option.
This allows a gateway to enforce the addrblock policy on certificates that
actually have the extension only. For (legacy) certificates not having the
extension, traffic selectors are validated/narrowed by other means, most
likely by the configuration.
When multihomed, a setup might prefer to dynamically stay on the cheapest
available path by using MOBIKE migrations. If the cheapest path goes away and
comes back, we currently stay on the more expensive path to reduce noise and
prevent potential migration issues. This is usually just fine for links not
generating real cost.
If we have more expensive links in the setup, it can be desirable to always
migrate to the cheapest link available. By setting charon.prefer_best_path,
charon tries to migrate to the path using the highest priority link, allowing
an external application to update routes to indirectly control MOBIKE behavior.
This option has no effect if MOBIKE is unavailable.
These options disable validation as such, e.g. even from cached CRLs, not
only the fetching. Also made the plugin's validate() implementation a
no-op if both options are disabled.
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).
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.
When charon rekeys a CHILD_SA after a soft limit expired, it is only
deleted after the hard limit is reached. In case of packet/byte limits
this may not be the case for a long time since the packets/bytes are
usually sent using the new SA. This may result in a very large number of
stale CHILD_SAs and kernel states. With enough connections configured this
will ultimately exhaust the memory of the system.
This patch adds a strongswan.conf setting that, if enabled, causes the old
CHILD_SA to be deleted by the initiator after a successful rekeying.
Enabling this setting might create problems with implementations that
continue to use rekeyed SAs (e.g. if the DELETE notify is lost).
With IKEv1 we have to reuse IKE_SAs as otherwise the responder might
detect the new SA as reauthentication and will "adopt" the CHILD_SAs of
the original IKE_SA, while the initiator will not do so. This could
cause CHILD_SA rekeying to fail later.
Fixes#1236.
This can be useful when writing custom plugins as typos or missing
linker flags that result in unresolved symbols in the shared object
could otherwise cause late crashes. In particular, if such a symbol
is used in a code path that is rarely executed. During development
and testing using RTLD_NOW instead of RTLD_LAZY will prevent the
plugin from getting loaded and makes the error visible immediately.
Some clients won't do Mode Config or XAuth during reauthentication.
Because Start messages previously were triggered by TRANSACTION exchanges
none were sent for new SAs of such clients, while Stop messages were still
sent for the old SAs when they were destroyed. This resulted in an
incorrect state on the RADIUS server.
Since 31be582399 the assign_vips() event is also triggered during
reauthentication if the client does not do a Mode Config exchange.
So instead of waiting for a TRANSACTION exchange we trigger the Start
message when a virtual IP is assigned to a client.
With this the charon.plugins.eap-radius.accounting_requires_vip option
would not have any effect for IKEv1 anymore. However, it previously also
only worked if the client did an XAuth exchange, which is probably
rarely used without virtual IPs, so this might not be much of a
regression.
Fixes#937.
The kernel uses NLMSG_GOODSIZE as default buffer size, which defaults to
the PAGE_SIZE if it is lower than 8192 or to that value otherwise.
In some cases (e.g. for dump messages) the kernel might use up to 16k
for messages, which might require increasing this value.
The specific traffic selectors from the acquire events, which are derived
from the triggering packet, are usually prepended to those from the
config. Some implementations might not be able to handle these properly.
References #860.
Tobias Brunner