The calculation of the timeout is also shared now and the total
timeout in seconds is corrected in case retransmit_base is <= 1.
This could make it easier in the future to apply different retransmission
settings to messages/exchanges.
Since these might conflict with IKE traffic, this requires special care.
One option is to install bypass policies for the peer, which install
appropriate (throw) routes. However, that won't work if the traffic to
the gateway itself should be protected, in particular, for host-to-host
tunnels. So an alternative is to set a mark for the IKE socket and then
exclude that traffic from table 220 via the kernel-netlink plugin's
fwmark option.
The manager will allow charon-nm to create XFRM interfaces if supported
by the kernel instead of creating an unused dummy TUN interface.
The xfrmi tool is mostly obsolete nowadays as iproute2 supports creating
XFRM interfaces since 5.1.0 (2019-05). Older Debians don't ship that and
early versions didn't list the interface IDs. So there might still be
some uses for this tool.
Since 6.2 the Linux kernel updates the last use time per SA. In
previous releases the attribute was only updated and reported for
specific outbound IPv6 SAs.
Using this reduces the number of kernel queries per CHILD_SA: for DPDs
from two policy queries (IN/FWD) to a single query of the inbound SA,
and for status reports the three policy queries (IN/FWD/OUT) can be
omitted and only the two SAs have to be queried. For NAT keepalives the
number of queries doesn't change but a policy query (OUT) is replaced by
a query for the outbound SA.
While we could use the existence of the attribute as indicator for its
support, we don't know this until we queried an SA. By using a version
check we can announce the feature from the start.
While this uses the same mechanism, it's not necessary to explicitly
enable port_bypass, the regular socket policies work fine to bypass any
software policies.
While the kernel defines it since 2005 (2.6.14), some older versions of
socket.h shipped with C libraries might not. In particular, glibc only
added it with 2.24 in 2016.
Closesstrongswan/strongswan#1503
With newer kernels (basic support for extended ACKs is there since 4.12
but some messages for XFRM were only added with 6.1) this gives more
detailed error messages to the user than e.g. a generic EINVAL or ENOSYS
error would.
Also enabled omitting the request payload in NLMSG_ERROR messages.
When watching the output of `swanctl -l` during debugging, the debug
messages in query_sa/policy() cause a lot of noise in the logs (level 2
for DBG_KNL still has actually useful information that we want to see
in the logs) and they're not very useful.
Compared to the messages in the functions above, the ones in update_sa()
and get_replay_state() are not seen often. But since there already is a
log message on level 2 in update_sa(), they're kinda redundant.
Closesstrongswan/strongswan#1271
Normally, GCC sees that we terminate the destination with a zero byte.
However, when using `-fsanitize=address`, there seems to be additional
instrumentation code after strncpy() so GCC produces warnings like
these:
‘__builtin_strncpy’ specified bound 16 equals destination size [-Wstringop-truncation]
This was originally added with 1551d8b13d ("kernel-netlink: reject
policy refcount if the reqid differs"). Since then we added code to
allocate constant reqids for the same TS, which pretty much avoids the
previous issues.
However, the reqid might have to be changed due to MOBIKE updates. And
because reqids are allocated for a complete set of traffic selectors and
not individual pairs, this can create a problem with drop policies as
those will use the old reqid (they are installed with the same priority,
reqid etc. to replace the actual IPsec policies), while unmodified
replacement policies will use the new one. A similar issue exists for
CHILD_SAs with SELinux contexts as those all use duplicate policies (same
generic label) but can't all be updated concurrently.
If a policy with IPComp template triggers an acquire, we get two, one for
an IPComp, one for ESP/AH SA. However, the triggering template of the trap
policy (where we get the reqid from), will be the same in both acquires,
IPComp, which we ignore, so no acquire was actually forwarded.
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.
Note that manually adding an IPv6 address without disabling duplicate
address detection (DAD, e.g. via `nodad` when using iproute2) will cause
a roam event due to a flag change after about 1-2 seconds (TENTATIVE is
removed). If this is a problem, we might have to ignore addresses with
TENTATIVE flag when we receive a RTM_NEWADDR message until that flag is
eventually removed.
Fixes#3511.
The main intention here is that we can change the hashtable_t
implementation without being impeded by the special requirements imposed
by get_match() and sorting the keys/items in buckets.
They are not marked as temporary addresses so make sure we always return
them whether temporary addresses are preferred as source addresses or not
as we need to enumerate them when searching for addresses in traffic selectors
to install routes.
Fixes: 9f12b8a61c ("kernel-netlink: Enumerate temporary IPv6 addresses according to config")
Enables us to ignore any future kernel features for routes unless
we actually need to consider them for the source IP routes.
Also enables us to actually really skip IPsec processing for those networks
(because even the routes don't touch those packets). It's more what
users expect.
Co-authored-by: Tobias Brunner <tobias@strongswan.org>
This happened when installing a duplicate bypass policy for a locally
connected subnet. The destructor and the kernel-net part already
handle this correctly.
Tobias Brunner