The addresses are actually the endpoints of the SA, not information on
the matched packet (except that the RFC says to set the ports and
protocol of the packet in the source address, which the Linux kernel
doesn't do). So these are useless, unless transport mode is used, where
the addresses are needed for the wildcard trap policy use case.
The RFC mentions a PROXY address (a single one, not two), that could
apparently be something like the source address in tunnel mode.
However, the description of how this is used in the RFC is quite weird
and neither Linux nor FreeBSD send such an attribute in SADB_ACQUIRE.
Note that while PF_KEYv2 also uses sequence numbers to identify acquires,
which we currently don't use correctly by the way, it does not include
information about the packet that triggered an acquire. What we receive
in src and dst, and currently forward as traffic selectors, are actually
the designated endpoints of the SA. So especially in tunnel mode this is
useless to do narrowing on the responder (these addresses might not even
match the configured TS).
With the sequence numbers we don't have to maintain the reqid to delete
the temporary state.
One exception is with labels. There we currently only install trap
policies with the generic label. SAs created from those don't have
policies installed, so we have to reuse the reqid of the trap even if
narrowing occurs.
And as before, we reuse the reqid without checking traffic selectors if
sequence numbers are not supported.
Note that if a CHILD_SA is manually initiated (i.e. has no sequence
number assigned) right before an acquire is triggered, there are several
possible outcomes depending on whether narrowing occurs. If there is no
narrowing, the same reqid is assigned and the kernel will remove the
temporary SA when the SA is installed (no seq => reqid match).
Afterwards, the queued duplicate CHILD_SA is destroyed and the acquire
state in the trap manager gets removed. If there is narrowing, a new
reqid is allocated, so the installation of the SA will not remove the
temporary state. However, due to the narrowing, the duplicate check
fails and when the duplicate is installed (with sequence number), the
temporary state is deleted (as is the state in the trap manager).
Optionally with "dynamic" traffic selectors resolved. A new method
is added for those cases where we actually want to select potentially
narrowed traffic selectors using a supplied list. The latter now also
always logs details, while the former does not.
Either use the sequence number from the kernel (and potentially update
it if the acquire was retriggered), or generate our own sequence
numbers, which simplifies matching acquires to established/destroyed
CHILD_SAs.
Threads initiating SAs can get stuck on the semaphore in
wait_for_listener() during shutdown if the corresponding job is never
executed. A particular case when this can happen is if more initiations
are triggered than worker threads are available. This causes a (known)
deadlock as no workers are free anymore to process jobs (for inbound
messages or timeouts etc.), including the one to initiate an SA.
This change at least allows a proper shutdown.
The plugin was apparently broken for years because it uses functions that
don't exist anymore. It was quite limited anyway, so it was never really
used in OpenWrt to begin with (instead they generate configs in a custom
init script).
This changes how EAP identities are used from the config. Instead of
setting a statically configured identity != %any, an EAP-Identity
exchange is now always initiated (and required). If the received identity
doesn't match, the peer config is switched to one with a matching
identity (wildcards are supported for that match). This allows switching
to a config with a different EAP method or child settings based on the
EAP identity.
There is currently no "best" match. The configs are evaluated based on
the order returned from the initial peer config lookup.
References strongswan/strongswan#2702
This enables GRO offload for inbound ESP-in-UDP packets if the
esp4|6_offload modules are loaded. Note that inbound ESP or ESP-in-UDP
packets won't be visible on layer 3 in Netfilter or tcpdump.
Increase buffer to 32 bytes to hold uint64_t completely and check for
overflows after multiplication with size modifiers.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
This requires a new protocol version as private extensions would enable
unrelated regular extensions, even when sending the private extension
as second attribute (which would work for conditions as they are
explicitly enabled/disabled).
This was originally added with b0e40caafb ("NAT-T conditions were not
inherited during IKE_SA rekeying") in 2008 when there was only a single
inherit() method. Later the inherit_pre() method was added and then
with 094963d1b1 ("ikev2: Apply extensions and conditions before
starting rekeying") in 2014 the extensions and conditions were set
already there.
This avoids conflicts with upstream changes if patched versions of
strongSwan require a number of private extensions and conditions. For
example, the following extensions can be used as usual via the
`enable|supports_extension()` methods:
#define PRIVATE_EXT_1 (EXT_PRIVATE_MARKER | (1<<0))
#define PRIVATE_EXT_2 (EXT_PRIVATE_MARKER | (1<<1))
Defining an enum would also be possible but because the type won't match
the values would have to be cast to `ike_extension_t` when using the
methods.
Similarly, `COND_PRIVATE_MARKER` may be used to define private conditions
that can be used with the `set|has_condition()` methods.
Because the MSB is explicitly not set in `private_extensions|conditions`,
these members may directly be checked against private values, e.g.:
if (this->private_extensions & PRIVATE_EXT_1)
{
}
As described in the previous commit, GCC 15 uses C23 by default and that
changes the meaning of such argument-less function declarations. So
whenever we assign such a function to a pointer that expects a function
with arguments it causes an incompatible pointer type warning. We
could define dedicated functions/callbacks whenever necessary, but this
seems like the simpler approach for now (especially since most uses of
these functions have already been cast).
Besides being clearer, this fixes issues with GCC 15. The latter uses
C23 by default, which changes the meaning of function declarations
without parameters such as
bool return false();
Instead of "this function takes an unknown number of arguments", this
now equals (void), that is, "this function takes no arguments". So we
run into incompatible pointer type warnings all over when using such
functions. They could be cast to (void*) but this seems the cleaner
solution for this use case.
This reverts commit f717bb5249.
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
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
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
This can be useful if the DHCP server runs on the same server. On Linux,
the response is then sent via `lo`, so packets won't be received if both
sockets are bound to e.g. a bridge interface.
In some setups the responses from the DHCP server are sent via lo, which
does not have an address of type `ARPHRD_ETHER` (the address length is
the same, though, just all zeros, by default). Note that the dhcp plugin
doesn't actually care for the MAC address or interface details, that's
only used by the farp plugin.
Fixes: 187c72d1af ("dhcp: Port the plugin to FreeBSD/macOS")
When serving as a responder and receiving an INFORMATIONAL exchange
containing INVALID_SYNTAX after IKE_AUTH, the IKE_SA should be deleted.
Currently, it only gets deleted after receiving AUTHENTICATION_FAILED.
RFC7296 section 2.21.2 says:
In an IKE_AUTH exchange, or in the INFORMATIONAL exchange immediately
following it (in case an error happened when processing a response to
IKE_AUTH), the UNSUPPORTED_CRITICAL_PAYLOAD, INVALID_SYNTAX, and
AUTHENTICATION_FAILED notifications are the only ones to cause the
IKE SA to be deleted or not created, without a Delete payload.
Closesstrongswan/strongswan#2636
Directly calling setup.py is deprecated (apparently has been for a while,
but now we get large warnings). Direct installation is also discouraged.
So this removes that option. The built wheel (the old egg format is not
used/built anymore) can be installed manually in a venv or the like.
Tobias Brunner