Such routes with a gateway that equals the peer's address are problematic
on FreeBSD. And since there is most likely a narrow route for the local
subnet anyway, the exclude routes would be redundant.
When installing routes based on remote traffic selectors, it can be
necessary to install an exclude route for the remote peer to avoid a
routing loop and continue to be able to reach it via IKE/ESP.
However, such routes are only necessary, if the routes we install don't
go via outbound interface. That's the case when using VIPs and routing
via TUN devices, or when using internal source IPs and routing via
their interfaces.
Installing such exclude routes if not necessary can cause issues on
FreeBSD (EINVAL when sending packets to the peer).
This can happen if an IKE_SA is initiated to a static IP before DHCP is
done. Instead of failing the initiation, we either fake a NAT situation
(for IPv4) or disable NAT-D (for IPv6 where NATs and UDP-encap are not
widely used or supported).
This also removes the old fallbacks to determine the source address(es).
A source address lookup is done in ike_sa_t::resolve_hosts() (wasn't the
case initially) and enumerating local IPs (which was added even earlier)
could still lead to issues if e.g. LAN addresses are available but the
WAN address that's later used is not yet (in which case only the responder
would detect a NAT and UDP-encap would be configured asymmetrically).
To force UDP-encap locally in case there is no actual NAT, we store this
as COND_NAT_HERE instead of COND_NAT_FAKE. This ensures DPDs will contain
NAT-D notifies and we can later remove the state via MOBIKE. We trigger
a MOBIKE update after such a DPD by registering a changed NAT mapping after
checking for a disappearing local NAT, which is very unlikely to happen
outside of a MOBIKE update (where that flag is not checked).
strongSwan logs all syslog messages using LOG_INFO for historical reasons,
regardless of the strongSwan loglevel used producing the log message.
In some setups with advanced logging infrastructure, it may be feasible
to be more verbose when logging in strongSwan, but then filter messages
on the syslog server. While this may be possible by custom syslog filtering
rules matching the log level included with the log_level setting, this is
not super convenient.
So add a new map_level setting, which can map strongSwan loglevels to
syslog loglevels. By default this is disabled, keeping the existing
behavior. If enabled, it maps strongSwan loglevels to syslog loglevels
at a given syslog loglevel offset.
Closesstrongswan/strongswan#859
RFC3779 requires to validate the addrblocks of issuer certificates strictly,
that is, they must contain the extension and the claimed addrblock, up to
the root CA.
When working with third party root CAs that do not have the extension,
this makes using the plugin impossible. So add a depth setting that limits
the number of issuer certificates to check bottom-up towards the root CA.
A depth value of 0 disables any issuer check, the default value of -1
checks all issuers in the chain, keeping the existing behavior.
Closesstrongswan/strongswan#860
Without this, the authentication succeeded if the server sent an early
EAP-Success message for mutual, key-generating EAP methods like EAP-TLS,
which may be used in EAP-only scenarios but would complete without server
or client authentication. For clients configured for such EAP-only
scenarios, a rogue server could capture traffic after the tunnel is
established or even access hosts behind the client. For non-mutual EAP
methods, public key server authentication has been enforced for a while.
A server previously could also crash a client by sending an EAP-Success
immediately without initiating an actual EAP method.
Fixes: 0706c39cda ("added support for EAP methods not establishing an MSK")
Fixes: CVE-2021-45079
This is useful for kernel implementations where the ordering of SAs
is unpredictable and the new SA might otherwise not be used until the
DELETE response has been received, which is not ideal as the responder
might not keep the old SA around that long. On Linux, it makes no
difference as we switch to the new outbound SA immediately because the
updated outbound policy references its SPI.
The default MTU of 1500 is too high if kernel-libipsec is used (considering
the overhead of UDP-encapsulated ESP), but might also have an effect if
a TUN device is only used to install a virtual IP (the route points to it,
so the system might use its MTU and 1500 would still be too high).
This also works around an issue on macOS 12 where no RTM_IFINFO event
is sent for the newly created TUN device (neither for the creation,
setting it "up", nor adding the address). Changing the MTU, however,
triggers such an event and we can detect the virtual IP.
Closesstrongswan/strongswan#707
Currently the length of vendor ID Cisco VPN Concentrator is 16
bytes but the string has only 13+1 bytes. The actual vendor
ID has 16 bytes with a prefix length of 14 bytes and two version
bytes.
Fixes: 6c49ddfbca ("ike: Add additional Vendor IDs for third-party implementations")
Before commit 6c49ddfbca ("ike: Add additional Vendor IDs for
third-party implementations") the prefix length of vendor ID
Cisco Unity was hardcoded to 14. Since we need to know the actual
length of this VID to send it, the length can't be overloaded
with a prefix length. Revert part of commit 6c49ddfbca to
fix this problem.
Fixes: 6c49ddfbca ("ike: Add additional Vendor IDs for third-party implementations")
Before commit 6c49ddfbca ("ike: Add additional Vendor IDs for
third-party implementations") the prefix length of vendor ID
MS NT5 ISAKMPOAKLEY was hardcoded to 16. Change the prefix length
accordingly.
Fixes: 6c49ddfbca ("ike: Add additional Vendor IDs for third-party implementations")
If there are many CHILD_SAs, the time between initiating the new IKE_SA
and checking it in might be longer (depending on what else is going on
in the daemon) than the retransmission timeout and no retransmits might
be sent afterwards for this SA (it will just linger around dead).
Calling initiate() last should avoid that (we do this similarly for MBB
reauthentication).
If we are using make-before-break reauthentication, this could lead to
duplicates as the new IKE_SA wouldn't be able to delete the previous
one if it was replaced by a rekeying.
If we initiated a make-before-break reauthentication and the peer
concurrently deletes the IKE_SA (e.g. because it uses break-before-make
reauthentication), we would create a duplicate IKE_SA (the condition forces
a recreation of all existing CHILD_SAs because reestablish() is also called
to complete a break-before-make reauthentication).
The addresses observed by the client behind the NAT are exactly the same if
the NAT router gets restarted.
Fixes: 2b255f01af ("ike-mobike: Use ike_sa_t::update_hosts() to trigger events")
If two threads are waiting in find_entry() and remove_entry(),
respectively, and the former is woken first, the latter remains stuck
as it won't get signaled.
If there are threads waiting in find_entry() and one in remove_entry()
and the latter is woken first by a thread calling put_entry(), the
former threads would remain stuck as they get never signaled.
This can happen if an IKE_SA is terminated forcefully shortly before
terminating the daemon. The thread that handles the terminate command
will call checkin_and_destroy(), which unregisters the IKE_SA from the
manager before destroying it. The main thread that calls flush() on the
IKE_SA manager won't wait for this SA (its entry is already gone), so
the processor and in turn the watcher job/thread might get canceled
before the first thread started deleting the VIP. It would then wait
indefinitely for a signal that can never be sent.
There is still a small chance the thread hangs in wait() if the state check
happens right before the watcher is canceled and it wasn't yet able to
deliver the event from the kernel, we counter that by rechecking the state
after a while.
Depending on how CLOCK_MONOTONIC is implemented, time_monotonic() might
return 0 within 1 second after the system is started. If that's the
case, we just default to 0 for now to avoid a crash (doesn't "hide" the
system time, but it's only the uptime anyway in this case).
Closesstrongswan/strongswan#435.
This now includes all key material derived for IKE_SAs in the order
defined in the RFC:
{SK_d | SK_ai | SK_ar | SK_ei | SK_er | SK_pi | SK_pr}
= prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr)
Signed-off-by: Thomas Egerer <thomas.egerer@secunet.com>
Tobias Brunner