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>
In order to avoid that the kernel uses virtual tunnel IPs for traffic
over physical interfaces we previously deprecated the virtual IP. While
this is working it is not ideal. This patch adds address labels for
virtual IPs, which should force the kernel to avoid such addresses to
reach any destination unless there is an explicit route that uses it as
source address.
%unique (and the upcoming %same key) are usable in specific contexts only.
To restrict the user from using it in other places where it does not get the
expected results, reject such keywords unless explicitly allowed.
We now check if there are other routes tracked for the same destination
and replace the installed route instead of just removing it. Same during
installation, where we previously didn't replace existing routes due to
NLM_F_EXCL. Routes with virtual IPs as source address are preferred over
routes without.
This should allow using trap policies with virtual IPs on Linux.
Fixes#85, #2162.
This can be useful if routing rules (instead of e.g. route metrics) are used
to switch from one to another interface (i.e. from one to another
routing table). Since we currently don't evaluate routing rules when
doing the route lookup this is only useful if the kernel-based route
lookup is used.
Resolvesstrongswan/strongswan#88.
If an interface is renamed we already have an entry (based on the
ifindex) allocated but previously only set the usable state once
based on the original name.
Fixes#2403.
For table dumps the kernel accepts RTA_PREFSRC to filter the routes, which is
what we do when doing userspace route calculations. For kernel-based route
lookups, however, the RTA_PREFSRC attribute is ignored and we must specify
RTA_SRC for policy based route lookups.
For gateways with many connections, installing routes is often disabled,
as we can use a static route configuration to achieve proper routing with
a single rule. If this is the case, there is no need to dump all routes and
do userspace route lookups, as there is no need to exclude routes we installed
ourself.
Doing kernel-based route lookups is not only faster with may routes, but also
can use the full power of Linux policy based routing; something we can hardly
rebuild in userspace when calculating routes.
The Optimistic Duplicate Address Detection (DAD) seems to fail in some
cases (`dadfailed` in `ip addr`) rendering the virtual IP address unusable.
Fixes#2183.
This implements rule 6 of RFC 6724 using the default priority table,
so that e.g. global addresses are preferred over ULAs (which also have
global scope) when the destination is a global address.
Fixes#2138.
A wrong variable is used (route instead of best), so much that the
returned interface belongs to the last seen route instead of the best
choice route.
get_route() may therefore return mismatching interface and gateway.
Fixes: 66e9165bc6 ("kernel-netlink: Return outbound interface in get_nexthop()")
Signed-off-by: Christophe Gouault <christophe.gouault@6wind.com>
Metrics are basically defined to order routes with equal prefix, so ordering
routes by metric first makes not much sense as that could prefer totally
unspecific routes over very specific ones.
For instance, the previous code did break installation of routes for
passthrough policies with two routes like these in the main routing table:
default via 192.168.2.1 dev eth0 proto static
192.168.2.0/24 dev eth0 proto kernel scope link src 192.168.2.10 metric 1
Because the default route has no metric set (0) it was used, instead of the
more specific other one, to determine src and next hop when installing a route
for a passthrough policy for 192.168.2.0/24. Therefore, the installed route
in table 220 did then incorrectly redirect all local traffic to "next hop"
192.168.2.1.
The same issue occurred when determining the source address while
installing trap policies.
Fixes 6b57790270 ("kernel-netlink: Respect kernel routing priorities for IKE routes").
Fixes#1416.
Tobias Brunner