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

[Harald Jenny]

On Wed, Oct 20, 2010 at 01:10:25AM +0200, Roel van Meer wrote:
> Paul Wouters writes:
> 
> >>> - routing into an ipsecX device, even for packets that have no SA, should
> >>>    fall through to the regular route if the value of failureshunt= is not
> >>>    changed from its default.
> >>
> >> Let me see if I understand you correctly: If I have a host (1.2.3.4) on a
> >> network 1.2.3.0/24, and it has these two routes:
> >>
> >> 1.2.3.0/24 dev eth1 proto kernel scope link src 1.2.3.4
> >> 1.2.3.0/24 dev ipsec0 proto kernel scope link src 1.2.3.4
> >>
> >> then even if the kernel selects the route through ipsec0 for the 1.2.3.0/24
> >> network, the packets should ultimately leave via eth1?
> > 
> > Yes, unless you have failureshunt=drop, OR you have a tunnel definition for
> > 1.2.3.0/24 -> somewhere that is in a %hold state (each loaded, but not up)
> 
> I haven't set failureshunt explicitly and I don't have a tunnel definition 
> for that network. Could you tell me how I can find out how failureshunt is 
> set?
> 
> Something else just occurred to me. We do carry Julian Anastasov's 
> advanced routing patches.

A that's a significant difference indeed...

> Maybe they are the cause why normal packets routed 
> into ipsec0 get blackholed. I'll build a kernel without those patches and 
> see if that will make a difference.

Sounds promising

> 
> >> I seem to need this because creating the ipsec0 device also installs a net
> >> route via the ipsec0 device, which causes my local network to become
> >> unreachable. Removing the extra route on ipsec0 fixed that.
> >>
> >> Said otherwise: I am not sure why I would need that route and it breaks my
> >> setup, so I was curious why it was there in the first place.
> >>
> >> (I'm aware that this is starting to be more appropriate for users@, so feel
> >> free to reply to that list of you want.)
> > 
> > Routing is how we get packets into the klips ipsec.ko kernel module for
> > encrypting. (netkey has its own special hooks with their own set of problems)
> > 
> > You might be right that you don't need the route.
> 
> Just so I can fully understand this: I understand the need for routing 
> packets via ipsec0 for networks that appear in tunnel definitions, but in 
> what scenario would it be necessary to route traffic for other networks via 
> ipsec0?

Hmmmm interesting question...

> 
> > I was not aware this was added because of ifconfig use.
> > David is expected to update _startklips for 2.6.32 now that we released
> > 2.6.31. So your issue might be solved in git over the next few days.
> 
> Well, I spoke too soon when I blamed ifconfig. Sorry about that. Reviewing 
> the updated _startklips script you posted taught me that both ip and 
> ifconfig add the route when used in identical ways.
> 
> That also means the new _startklips behaves identical to the old one, so the 
> problem I'm having is still there. Thank you for posting it, though.
> 
> Anyhow, I'd like to thank you for your time so far. I must say it's a very 
> annoying little problem, since it is so very easy to apply one of several 
> workarounds, but so very hard to understand the cause of it.

In the end I guess everbody will have learned much ;-).

> 
> Regards,
> 
> roel

Kind regards
Harald

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