[Openswan dev] [PATCH] Incorrect automatic route via ipsec0
Roel van Meer
rolek at bokxing.nl
Tue Oct 19 19:10:25 EDT 2010
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 (22.214.171.124) on a
>> network 126.96.36.199/24, and it has these two routes:
>> 188.8.131.52/24 dev eth1 proto kernel scope link src 184.108.40.206
>> 220.127.116.11/24 dev ipsec0 proto kernel scope link src 18.104.22.168
>> then even if the kernel selects the route through ipsec0 for the 22.214.171.124/24
>> network, the packets should ultimately leave via eth1?
> Yes, unless you have failureshunt=drop, OR you have a tunnel definition for
> 126.96.36.199/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
Something else just occurred to me. We do carry Julian Anastasov's
advanced routing patches. 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.
>> 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
> 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.
More information about the Dev