Some servers might not support a length of 32 and return a malformed
request error. Lowering the value to the previous default of 16 could
help in that case.
This allows preventing peers from authenticating with certificates
that are locally trusted, in particular, our own local certificate (which
safeguards against accidental reuse of certificates on multiple peers).
On the other hand, if this option is enabled, end-entity certificates
for peers can't be configured anymore explicitly (e.g. via remote.certs
in swanctl.conf).
Some third party IKEv2 products expect an RSA-PSS ASN.1
algorithmIdentifier with an explicit trailerField value (CONTEXT3)
instead of the DEFAULT value if the trailerField is missing.
The setting charon.rsa_pss_trailerfield = yes enables the explicit
encoding.
These only apply to the usage reports that are available via
`stroke memusage`, not to leak reports when executables are terminated,
which always include all non-whitelisted leaks.
This should make the DoS limits (cookie_threshold[_ip] and block_threshold)
more accurate so that it won't be possible to create lots of jobs from
spoofed IP addresses before half-open IKE_SAs are actually created from
these jobs to enforce those limits.
Note that retransmits are tracked as half-open SAs until they are
processed/dismissed as the check only happens in checkout_by_message().
Increasing the count in process_message_job_create() avoids issues with
missing calls to track_init() before calling checkout_by_message() (e.g.
when processing fragmented IKEv1 messages, which are reinjected via a
process message job).
Because the global cookie threshold is higher than the per-IP block
threshold, it was previously possible for an attacker to block a legitimate
user by sending spoofed IKE_SA_INIT packets from that user's IP.
The timespan for requiring cookies is now also not extended anymore with
every IKE_SA_INIT received during the calm down period. Because this
allowed an attacker, after initially triggering the global cookie threshold,
to force cookies for all clients by sending just a single spoofed
IKE_SA_INIT every 10 seconds.
We keep track of reaching the per-IP threshold in segments of the hashed
IP addresses, so only a (random, due to chunk_hash()'s random key) subset
of clients will receive cookies, if single IPs are targeted.
The default global threshold is increased a bit.
Usually, the DNs of all loaded CA certificates are included in the
CertificateRequest messages sent by the server.
Alas, certain EAP-TLS clients fail to process this message if the
list is too long, returning the fatal TLS alert 'illegal parameter'.
This new option allows configuring whether CAs are included or an
empty list is sent (TLS 1.2), or the certificate_authorities extension
is omitted (TLS 1.3). The list only serves as hint/constraint
for clients during certificate selection, they still have to provide
a certificate but are free to select any one they have available.
Closesstrongswan/strongswan#187.
A new global option enables sending this vendor ID to prevent Cisco
devices from narrowing the initiator's local traffic selector to the
requested virtual IP, so e.g. 0.0.0.0/0 can be used instead.
This has been tested with a "tunnel mode ipsec ipv4" Cisco template but
should also work for GRE encapsulation.
Closesstrongswan/strongswan#180.
This is useful on Android where the app might not be able to send
keep-alives if the device is asleep for a while. If the NAT mapping
has been deleted in the mean time, the NAT-D payloads allow detecting
this and connectivity can be restored by doing a MOBIKE update or
recreating the SA if the peer already deleted it because the client
wasn't reachable.
Some peers apparently don't send the notify and still expect to
authenticate with EAP-only authentication. This option allows forcing
the configured use of EAP-only authentication in that scenario.
Charon refuses to make use of algorithms IDs from the private space
for unknown peer implementations [1]. If you chose to ignore and violate
that section of the RFC since you *know* your peers *must* support those
private IDs, there's no way to disable that behavior.
With this commit a strongswan.conf option is introduced which allows to
deliberately ignore parts of section 3.12 from the standard.
[1] http://tools.ietf.org/html/rfc7296#section-3.12
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
Might be useful for users of other daemons too. Note that compared to the
previous implementation in charon-tkm, the mask/label are applied in
network order.
Closesstrongswan/strongswan#134.
After deleting a rekeyed CHILD_SA we uninstall the outbound SA but don't
destroy the CHILD_SA (and the inbound SA) immediately. We delay it
a few seconds or until the SA expires to allow delayed packets to get
processed. The CHILD_SA remains in state CHILD_DELETING until it finally
gets destroyed.
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.
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).
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.
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.
If this is disabled the schemes configured in `rightauth` are only
checked against signature schemes used in the certificate chain and
signature schemes used during IKEv2 are ignored.
Disabling this could be helpful if existing connections with peers that
don't support RFC 7427 use signature schemes in `rightauth` to verify
certificate chains.
With make-before-break IKEv2 re-authentication, virtual IP addresses must be
assigned overlapping to the same peer. With the remote IKE address, the backend
can detect re-authentication attempts by comparing the remote host address and
port. This allows proper reassignment of the virtual IP if it is re-requested.
This change removes the mem-pool.reassign_online option, as it is obsolete now.
IPs get automatically reassigned if a peer re-requests the same address, and
additionally connects from the same address and port.
