This also restores the charon.signature_authentication_constraints
functionality, that is, if no explicit IKE signature schemes are
configured we apply all regular signature constraints as IKE constraints.
This adds support for IKEv2 redirection (RFC 5685). There is currently
no default implementation of the redirect_provider_t interface provided.
Plugins may implement the interface to decide if and when to redirect
connecting clients. It is also possible to redirect established IKE_SAs
via VICI/swanctl.
An attacker could blindly send a message with invalid nonce data (or none
at all) to DoS an initiator if we just destroy the SA. To prevent this we
ignore the message and wait for the one by the correct responder.
If the SA got redirected this would otherwise cause a reauthentication with
the original gateway. Reestablishing the SA to the original gateway, if e.g.
the new gateway is not reachable makes sense though.
We handle this similar to how we do reestablishing IKE_SAs with all CHILD_SAs,
which also includes the one actively queued during IKE_AUTH.
To delete the old SA we use the recently added ike_reauth_complete task.
To prevent the creation of the CHILD_SA we set a condition on the
IKE_SA. We also schedule a delete job in case the client does not
terminate the IKE_SA (which is a SHOULD in RFC 5685).
According to the mode-config draft there is no prefix sent for
IPv6 addresses in IKEv1. We still accept 17 bytes long addresses for
backwards compatibility with older strongSwan releases.
Fixes#1304.
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).
If it was necessary to pass the local certificates we could probably
clone the config (but we don't do that either when later looking for the
key to actually authenticate).
Passing auth adds the same subject cert to the config over and over
again (I guess we could also try to prevent that by searching for
duplicates).
The structs that make up a message sent to the kernel have all to be
aligned with XT_ALIGN. That was not necessarily the case when
initializing the complete message as struct.
Fixes#1212.
If there is no path to the other peer there is no point in trying to
send a NAT keepalive.
If the condition changes back and forth within the keepalive interval there
is a chance that multiple jobs get queued.
/usr/local/sbin is not included in PATH set by the charon init script and
since the ipsec script is obsolete when using swanctl it makes sense to
change this anyway.
This could be helpful when debugging deadlocks that manifest around
wait_for_entry(), as it helps identifying other involved threads (the
thread object is seen in the thread_main() call in each thread's backtrace).
An example are the fallback drop policies installed when updating SAs.
We ignore such policies in add_policy() so there is no point in attempting
to remove them. Since they use different priorities than regular policies
this did not result in policies getting deleted unintentionally but there
was an irritating log message on level 2 that indicated otherwise.
If DPD timeout is set but to a value smaller than the DPD delay the code
in task_manager_v1.c:queue_liveliness_check will run into an integer
underrun.
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.
Otherwise, libcharon's dependency on kernel-ipsec can't be satisfied.
This changed with db61c37690 ("kernel-interface: Return bool for
kernel interface registration") as the registration of further
kernel-ipsec implementations now fails and therefore even if other
plugins are loaded the dependency will not be satisfied anymore.
References #953.
When handling a rekey collision we might have to delete an already
installed redundant CHILD_SA (or expect the other peer to do so).
We don't want to trigger updown events for these as neither do we do
so for successfully rekeyed CHILD_SAs.
Fixes#853.
To handle Phase 2 exchanges on the other HA host we need to sync the last
block of the last Phase 1 message (or the last expected IV). If the
gateway is the initiator of a Main Mode SA the last message is an
inbound message. When handling such messages the expected IV is not
updated until it is successfully decrypted so we can't sync the IV
when processing the still encrypted (!plain) message. However, as responder,
i.e. if the last message is an outbound message, the reverse applies, that
is, we get the next IV after successfully encrypting the message, not
while handling the plain message.
Fixes#1267.
It is required for IKEv1 to determine the DH group of the CHILD SAs
during rekeying. It also fixes the status output for HA SAs, which so
far haven't shown the DH group on the passive side.
Fixes#1267.
If the retransmit of an initial message is processed concurrently with the
original message it might not have been handled as intended as the
thread processing the retransmit might not have seen the correct value
of entry->processing set by the thread handling the original request.
For IKEv1, i.e. without proper message IDs, there might still be races e.g.
when receiving a retransmit of the initial IKE message while processing the
initiator's second request.
Fixes#1269.
Make sure commands registered in pki and swanctl don't exceed the
maximum number of lines available for their usage summary.
Closesstrongswan/strongswan#22.
Since the move to Google Compute Engine (GCE) IPv6 has been disabled
on the build hosts, causing several tests to fail. Lets try to get at
least local IPv6 connectivity up again.
Tobias Brunner