[Openswan dev] [PATCH] Incorrect automatic route via ipsec0

[Roel van Meer]

Harald Jenny writes:

>> > I guess it would be very beneficial to know your config?
>> 
>> Here goes:
>> distro: slackware 13.1
>> kernel: vanilla 2.6.32.23-2
>> openswan: 2.6.29
>> 
>> minimal ipsec.conf with which I can reproduce my issue:
>> ---/---
>> version 2.0
>> config setup
>>    interfaces="ipsec0=eth1"
>>    oe=off
>>    protostack=klips
>> ---/---
> 
> I miss a conn defintion in here - Paul does this trigger a bug in adding
> connections?

This is the smallest config file I can reproduce the issue with. Adding conn 
definitions does not change it. The problem is not related to routes for 
conns, but it is related to the routes that get installed when ip addresses 
are assigned to the ipsec device. That's why I posted the config without any 
conn definitions. I just tried to keep things as clear as possible. Sorry if 
I added to the confusion.

>> Routing setup before starting openswan (from ip ro sh):
>> ---/---
>> 87.253.148.0/25 dev eth1  proto kernel  scope link  src 87.253.148.33
>> 10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.1
>> prohibit 10.0.0.0/8
>> 127.0.0.0/8 dev lo  scope link
>> default via 87.253.148.1 dev eth1  metric 1
>> ---/---
>> 
>> Routing after starting openswan:
>> ---/---
>> 87.253.148.0/25 dev eth1  proto kernel  scope link  src 87.253.148.33
>> 87.253.148.0/25 dev ipsec0  proto kernel  scope link  src 87.253.148.33  
>> 10.0.0.0/24 dev eth0  proto kernel  scope link  src 10.0.0.1
>> prohibit 10.0.0.0/8
>> 127.0.0.0/8 dev lo  scope link
>> default via 87.253.148.1 dev eth1  metric 1
>> ---/---
>> 
>> In the second set of routes, you can see two routes to 87.253.148.0/25. 
>> Requesting a route to a locally connected host gives me:
>> 
>> root at host:~# ip ro get 87.253.148.126
>> 87.253.148.126 dev ipsec0  src 87.253.148.33 
>>     cache  mtu 1500 advmss 1460 hoplimit 64
>> 
>> As you see, the route goes via ipsec0, not via eth1, as I would have 
>> expected. When this happens, all traffic to 87.253.148.0/25 is routed via 
>> ipsec0 but it never leaves the box.
> 
> Sounds logic

But the how can it work on other systems? I'm starting to believe I'm 
missing something very obvious here. I almost can't believe this is an 
openswan problem if I'm the only one that gets bitten by it.

>> My first solution was to just remove this route, but then I found the 
>> workaround in _startklips for the ubuntu bug and I thought I'd extend that.
> 
> I'm not sure this is the case.

Well, it is related to the problem I am experiencing. The logic of 
_startklips is now:

- if you have any metric 0 routes on phys, add metric 0 routes to virt 
- if you have any metric n routes on phys (for n > 0) add metric n+1 routes 
to virt

The patch I posted changed that to:

- if you have any metric n routes on phys (for n >= 0) add metric n+1 routes 
to virt

which solves my problem, since the kernel now always picks the correct route 
for traffic to the link network.

Regards,

roel