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

[Paul Wouters]

On Mon, 18 Oct 2010, Roel van Meer wrote:

> surely there's someone with an opinion on this?
> If I need to give more information, please let me know.

- _startklips is set to be updated to use the ip command
- 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.

>> I'm noticing a problem with my routing after starting openswan with klips.
>> After starting, I have the same routes for my ipsec0 device as for eth1 (the
>> associated physical device). Since both routes have also the same metric, a
>> route lookup for locally connected devices returns a route through the
>> ipsec0 device, not a route through the eth1 device.
>>
>> I've noticed that the _startklips script contains the section below, where
>> the route metric is updated if the original route has a specified metric,
>> but this is not done if the original route has metric 0.
>>
>> ---/ original _startklips snippet /---
>> # configure the device
>> ifconfig $virt inet $phys_addr $phys_type $phys_otheraddr netmask $phys_mask mtu $phys_mtu
>>
>> # do we have to fix the route metric for this device?
>> maxmetric=$(ip route show $phys_otheraddr/$phys_mask | sed -n -e 's/.*metric \([0-9]\+\)/\1/p' | sort -n | tail -n1)
>> if [ -n "$maxmetric" ] ; then
>>         # If there are other none-zero-metric routes that match this spec
>>         # (the case on Ubuntu 10.04, Lucid) then move the route to the end.
>>         newmetric=$(( $maxmetric + 1))
>>         oldroute=$(ip route show $phys_otheraddr/$phys_mask dev $virt)
>>         ip route del $oldroute dev $virt
>>         ip route add $oldroute dev $virt metric $newmetric
>> fi
>> ---//---
>>
>> So my questions are:
>> - is this intentional?
>> - If so, why?

>From git commit 99634880325

     ipsecX route metric fix for Ubuntu 10.04

     on startup, ipsecX route would have a metric of 0, but the systems' route for
     the real device would have a route with metric 1.  That means, that as soon as
     an SA with that route was initailzied, no packets woudl ever make it out on
     that route.

     This commit will detect a case where another route exists with a non-zero
     metric that matches the spec assigned to the ipsecX device.  If that route
     is found, it will be moved to a higher metric an the other routes.

     At this time only Ubuntu 10.04 is known to create system routes with metric
     of 1.  Other systems should not be effected by this change.


>> - And in that case, how can I configure openswan in such a way that traffic
>> to my local net is routed through eth1, not ipsec0? (I'd rather not change
>> my routing or use hacks like adding postpluto commands..)

I am not sure why you would need this?

Paul