Source IP and installed routes might be incorrect when using auto=route if existing routes have metrics set
I'm trying to set up two connections (type=tunnel and type=passthrough).
strongSwan 5.4.1dr1, Linux 3.19.0-32-generic, x86_64
ip a s
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether e8:23:9d:47:17:ed brd ff:ff:ff:ff:ff:ff inet 10.224.86.5/17 brd 10.224.127.255 scope global eth0 valid_lft forever preferred_lft forever
ip r s
default via 10.224.100.1 dev eth0 proto static 10.224.0.0/17 dev eth0 proto kernel scope link src 10.224.86.5 metric 1
conn all-tun type=tunnel rightsubnet=10.0.0.0/8 ... auto=start conn lan-clear type=passthrough leftsubnet=10.224.0.0/17 rightsubnet=10.224.0.0/17 auto=route
After ipsec start ip r l table 220
10.0.0.0/8 via 10.224.100.1 dev eth0 proto static src 10.224.86.5 10.224.0.0/17 via 10.224.100.1 dev eth0 proto static src 10.224.86.5
And all traffic goes to the gateway 10.224.100.1.
I change the route and everything works as it should
ip r c table 220 10.224.0.0/17 dev eth0 proto static src 10.224.86.5
How to configure strongSwan that he did not add a gateway to route if the subnet is the same as the subnet of the host (leftsubnet)?
left|rightnexthop = %direct - removed
kernel-netlink: Order routes by prefix before comparing priority/metric
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"
The same issue occurred when determining the source address while
installing trap policies.
Fixes 6b57790270fb ("kernel-netlink: Respect kernel routing priorities for IKE routes").
#1 Updated by Tobias Brunner over 4 years ago
- Tracker changed from Issue to Bug
- Category set to kernel
- Status changed from New to Feedback
- Target version set to 5.5.0
- Resolution set to Fixed
... metric 1
Looks like this is the problem. A while ago (6b57790270) we started sorting routes by priority/metric before comparing the prefix length. Therefore, since the default route has priority 0 it will be ordered before the other route (even if it is more specific). So the next hop is taken from the default route instead of the other one (which does not define one as the subnet is directly attached). You can see in the ikev2/shunt-policies-nat-rw scenario that the route installation works correctly if the routes have the same metric.
Sorting by metric and then by prefix makes not much sense to me. We should do this the other way around as metrics are basically defined to order two routes with equal prefix. I did so in the 1416-route-order branch.