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.
The previous approach had two drawbacks:
First, it caused duplicate public keys because when the `certificate_t`
object was created and added to the credential set it had no subject
assigned yet. So it defaulted to the key ID. However, all previously
loaded keys had their subject already changed to an identity, so there
never was a match and new objects were always added whenever a config
with raw public keys was loaded.
Second, the subject was replaced in a way that's not thread-safe on an
object that's already shared in the public credential set. So other
threads could potentially access the `identification_t` object that's
destroyed during that process.
References strongswan/strongswan#853Closesstrongswan/strongswan#2561
If a migrate of a child-create occurs then labels_i and labels_r are
freed, but the pointers are left set. If the task is subsequently
destroyed without being reused, then both of these will be double
freed.
Fix this by setting labels_i and labels_r to NULL in the migrate
method after freeing, similar to other fields that are freed.
Closesstrongswan/strongswan#2552
Fixes: f9b895b49f ("child-create: Add support to handle security labels")
Both variables `inbound_installed` and `outbound_state` are used in
`child_sa_t::destroy()` to determine whether inbound and outbound state
have to be deleted. They are assigned prior to the call to
`kernel_interface_t::add_sa()`. As this call may fail, the destructor may
try to delete a state which it has not been added.
By making the assignment of these variables dependent on the success of
the state addition, we can make sure, a `child_sa_t::destroy()` only
deletes states it has added.
Also removed the redundant checks for `my_spi` and `other_spi` being set
along with the check for the above flags. It seems that when the flags
are set, the SPIs *must* be set.
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
If uniqueness checks are disabled and multiple IKE_SAs with the same
identities are created, an offline lease could have gotten reassigned
during a make-before-break reauthentication if such an SA was closed
earlier. Checking for an online lease for the same client (IP/port)
first ensures that the correct IP is reassigned during the
reauthentication.
References strongswan/strongswan#2472
Since we now open sockets for each address family independently (via
IPV6_V6ONLY) and without SO_REUSEADDR, it could happen with the previous
order on Linux that opening the port that was allocated as ephemeral
port for IPv6 was already used by a different process for IPv4.
Most IPv6 sockets on ephemeral ports will not have IPV6_V6ONLY set, so
the same port is also reserved for IPv4. Therefore, it's save to assume
that any ephemeral port we first get for IPv4 is free for IPv6.
References strongswan/strongswan#2494
The order was different when not setting `esp_proposals` or explicitly
configuring `default`.
Fixes: 33412158f5 ("ike: Send AEAD ESP default proposal first")
Similar to the previous commit. Instead of
generating rule 10 (1258)
followed by (or not if the list is empty)
generating payload of type PROPOSAL_SUBSTRUCTURE
we now get
generating rule 10 LIST of PROPOSAL_SUBSTRUCTURE
in the debug log.
Instead of this
parsing rule 10 (1258)
we now see this
parsing rule 10 LIST of PROPOSAL_SUBSTRUCTURE
in the debug log. Particularly useful if the list is empty as there won't
be a message like this following it:
x bytes left, parsing recursively PROPOSAL_SUBSTRUCTURE
This is particularly important for IKE_SAs that are not yet established,
which would get terminated as they have no established CHILD_SAs yet.
Fixes: 72f9a21b22 ("Merge branch 'vici-reload-actions'")
Otherwise, all configs would be considered to even some degree as the
ports usually match.
Closesstrongswan/strongswan#2441
Fixes: 9228a5109b ("ike-cfg: Consider port information in IKE config match")
Previously, it could happen that child_rekey() was triggered twice for
the same "old" SA. For listeners that would mean they'd loose track as
they'd be tracking a new SA that wasn't relevant anymore and for which
no updown event would ever get triggered (it was the redundant SA in a
collision). This new assert ensures that events are triggered in a
predictable way and listeners can track SAs properly.
As the winner of a rekey collision, we previously always triggered the
child_rekey() event once when creating the redundant SA on behalf of the
peer in the passive child-rekey task and then a second time when
creating the winning SA in the active task. However, both calls passed
the replaced CHILD_SA as "old". This made tracking CHILD_SAs impossible
because there was no transition from the redundant, "new" SA of the
first event to the "new", winning SA of the second. Of course, when the
second event was triggered, the redundant SA might not have existed
anymore because the peer is expected to delete it, which could happen
before the CREATE_CHILD_SA response arrives at the initiator.
This refactoring ensures that the child_rekey() event is triggered in
a way that makes the CHILD_SAs trackable in all reasonable (and even
some unreasonable) scenarios. The event is generally only triggered
once after installing the outbound SA for the new/winning CHILD_SA.
This can be when processing the CREATE_CHILD_SA in the active child-rekey
task, or when processing the DELETE for the old SA in a passive
child-delete task. There are some cases where the event is still
triggered twice, but it is now ensured that listeners can properly
transition to the winning SA.
Some corner cases are now also handled correctly, e.g. if a responder's
DELETE for the new CHILD_SA arrives before its CREATE_CHILD_SA response
that actually creates it on the initiator. Also handled properly are
responders of rekeyings that incorrectly send a DELETE for the old
CHILD_SA (previously this caused both, the new and the old SA, to get
deleted).
It also changes that payloads are built before installing the CHILD_SA
on the responder, that is, the KE payload is generated before keys are
derived, so that key_exchange_t::get_public_key() is called before
get_shared_secret(), or its internal equivalent, which could be relevant
for KE implementations that want to ensure that the key can't be
accessed again after the key derivation.
Initially, this is handled with a key derivation for each
IKE_INTERMEDIATE exchange. When rekeying, the keys are derived only
once all IKE_FOLLOWUP_KE exchanges are done.
The message ID of the first IKE_AUTH exchange is a safe-guard against
potential truncation attacks if IKE_INTERMEDIATE exchanges are not used
for multiple key exchanges but some other future use where the number of
exchanges might not depend on the selected proposal.