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

[Roel van Meer]

Hi Harald,

I'm replying to your mails all at once.

> is this bug also present in older releases of Ubuntu?

Not sure: I'm using Slackware and the problem I'm having is related to (but
not the same as) a problem with ubuntu that was fixed by the commit Paul 
provided.

> Sounds to me like Ubuntu made a change which simply breaks a script... I'm
> running Debian on some machines without any such issues.

It's not Ubuntu-related. If it is a distro-specific issue then it's a 
Slackware issue.

> 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
---/---

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.

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 hope I explained the situation a bit better now. I think it all boils down 
to the question of why _startklips creates a route through ipsec0 for my 
locally connected network.

Regards,

roel