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

[Roel van Meer]

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

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

Regards,

roel