Bug #1416: Source IP and installed routes might be incorrect when using auto=route if existing routes have metrics set - strongSwan

Bug #1416

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

Added by Pavel Kopchyk over 9 years ago. Updated over 9 years ago.

Status:

Closed

Priority:

Normal

Assignee:

Tobias Brunner

Category:

kernel

Target version:

5.5.0

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

History

#1 Updated by Tobias Brunner over 9 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 (commit: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 over 9 years ago

Status changed from Feedback to Closed
Assignee set to Tobias Brunner

#3 Updated by Tobias Brunner over 9 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

Project

General

Profile