Project

General

Profile

Bug #1416

Source IP and installed routes might be incorrect when using auto=route if existing routes have metrics set

Added by Pavel Kopchyk about 3 years ago. Updated almost 3 years ago.

Status:
Closed
Priority:
Normal
Category:
kernel
Target version:
Start date:
18.04.2016
Due date:
Estimated time:
Affected version:
dr|rc|master
Resolution:
Fixed

Description

Hi,

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 

connections

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

Associated revisions

Revision 3f4cc30b (diff)
Added by Tobias Brunner almost 3 years ago

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"
192.168.2.1.

The same issue occurred when determining the source address while
installing trap policies.

Fixes 6b57790270fb ("kernel-netlink: Respect kernel routing priorities for IKE routes").
Fixes #1416.

History

#1 Updated by Tobias Brunner about 3 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.

#2 Updated by Tobias Brunner almost 3 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner

#3 Updated by Tobias Brunner almost 3 years ago

  • Subject changed from type=passthrough and auto=route to Source IP and installed routes might be incorrect when using auto=route if existing routes have metrics set

Also available in: Atom PDF