This reverts commit f717bb5249caea550bc6e2baeb09ca309ad83b39.
Causes issues in our testing environment. Default route via host is
preferred if no gateway is set in the installed routes. Needs some
investigation.
References strongswan/strongswan#2548
If the client's network goes down for a while but the same IP address
is assigned later, it won't be aware if the server killed the IKE_SA
while it wasn't reachable. This way, a DPD is triggered and the client
can reestablish the SA if necessary. When roaming to a different IP,
a MOBIKE update is triggered with the same effect.
References strongswan/strongswan#2696
These have specific values for charon-nm's use case but might have to be
changed for special setups or because of conflicts.
References strongswan/strongswan#2683
Listeners can't track those IKE_SAs otherwise. For break-before-make
reauthentications, these events are already triggered because that is
implemented by calling reestablish() on the old IKE_SA.
When using port 4500 for IKE_SA_INIT, Windows Server 2016, 2025 and
possibly others send back all packets to the port initially used by the
client, not the one floated to before sending IKE_AUTH. So if UDP
encapsulation is used, no traffic can be received as the initial socket
can't have UDP decapsulation enabled.
tcpdump output:
```
IP <client-ip>.47547 > <server-ip>.4500: UDP-encap: ESP(spi=0xfd4e5fc2,seq=...)
IP <server-ip>.4500 > <client-ip>.57962: UDP-encap: ESP(spi=0xccc5e213,seq=...)
```
Avoid this by floating early if a non-default destination port is used.
This also ensures we don't send packets from port 500 (without non-ESP
marker) if ephemeral source ports are not used.
Closesstrongswan/strongswan#2664
Signed-off-by: Michael Braun <michael-dev@fami-braun.de>
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
Without UDP-encapsulation, the IKE and ESP traffic is not directly related
(other than via IPs), so firewalls might no keep the state for IKE traffic
alive if there is no IKE traffic for a while and constant ESP traffic
prevents DPDs from being exchanged because inbound ESP traffic is
considered.
Closesstrongswan/strongswan#1759
Using a specific address can be useful in scenarios where dynamic routing
could change the path to the RADIUS server and a changing source address
is a problem for the server.
Closesstrongswan/strongswan#2598
Adds support for multiple key exchanges to the ha plugin. Also,
because of the delayed key derivation and the not synced IntAuth
values, incomplete IKE_SAs are now destroyed during a failover.
Closesstrongswan/strongswan#2550
The node that gets activated usually won't be able to complete the
IKE_SA mainly because the IKE keys are now derived delayed, so the key
material required to process a message often won't be available (only
later IKE_AUTH messages and retransmits of earlier messages that the
active node already received and synced the keys for may be decrypted).
A second issue affects IKE_SAs with multiple key exchanges. Because the
IntAuth value(s) are currently not synced, which are necessary to
verify/create the AUTH payloads, the IKE_AUTH exchange couldn't be
completed.
Synchronization for the additional transforms in the IKE and Child SA
proposals is added. Details of the IKE_SA synchronization are changed
to support IKE_INTERMEDIATE exchanges that cause multiple HA_IKE_ADD
messages and key derivations. The cache has been extended to handle
multiple such messages.
Co-authored-by: Thomas Egerer <thomas.egerer@secunet.com>
This doesn't really seem useful (perhaps it was before we started to
configure the outbound interface on our routes). And it can actually
cause the route installation to fail e.g. for routes over point-to-point
interfaces where we'd get "Error: Nexthop has invalid gateway" errors.
Closesstrongswan/strongswan#2548
Currently, the runner images enable break-system-packages globally.
However, this workaround will be removed by the end of March. So
we switch to installing these packages as intended via distro (the
alternative would be to use pipx, at least for tox).
Fixes issues with reauthentication, in particular, to reestablish the
SA if MOBIKE is disabled. The app currently can't handle
make-before-break reauthentication. In part because necessary events are
currently not triggered. So for now, we switch back to the classic
reauthentication approach.
The service implementation with its handling of reauth callbacks and
no-DNS TUN device etc. can't handle make-before-break reauthentication
at the moment.
There was an issue with OPENSSL_armcap_P in Android's static build for
OpenSSL 3.1.1+. This was finally fixed with this release (and was also
backported to older versions).
Unspecified settings should be set to null, while some MDMs might send
them as empty strings, which could cause issues (like an empty password
or trying to parse an empty DNS server address).
This can happen with empty strings, which might be set for managed
profiles, which caused the refcounting to be askew and the resolver not
to work after connecting once because it was flushed and disabled.
