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

[Harald Jenny]

On Wed, Oct 20, 2010 at 12:38:58AM +0200, Roel van Meer wrote:
> 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.

Looks very weird to me as I use almost the same config section...

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

The short answer: Because it doesn't do that - at least not over here (running
currently a VPN).

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

I guess there is something with interferes with KLIPS.

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

I'm currently running the old startscript here and it works for me :-/.

> 
> Regards,
> 
> roel

Kind regards
Harald

> 
> _______________________________________________
> Dev mailing list
> Dev at openswan.org
> http://lists.openswan.org/mailman/listinfo/dev