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

[Roel van Meer]

Hi,

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

Attached is a patch to 2.6.29 _startklips that changes its behaviour to 
also update the new route metric if there are existing routes with metric 0.

As a related question: the use of ifconfig for setup of the virtual device 
causes this route to be added automatically. Wouldn't it be cleaner to use 
ip link and ip addr calls for this? Then we can add the correct route 
ourselves, instead of changing what we automatically got and maybe didn't 
like. If you want, I could make a patch for this too.

Regards,

roel

-------------- next part --------------
When _startklips creates a klips virtual interface, a local network route is 
automatically added for this virtual interface. If other routes have a
metric > 0, the metric of the new route is changed to one higher than the
largest existing metric, but if the metric of the other routes is 0, the
metric of the new route remains 0 as well. This breaks routing in some
setups, so we now ensure the metric of the new route is also increased if
there are existing routes with metric 0.

diff -ruN openswan-2.6.29.a/programs/_startklips/_startklips.in openswan-2.6.29.b/programs/_startklips/_startklips.in
--- openswan-2.6.29.a/programs/_startklips/_startklips.in	2010-09-27 18:40:32.000000000 +0200
+++ openswan-2.6.29.b/programs/_startklips/_startklips.in	2010-09-30 08:24:37.000000000 +0200
@@ -219,10 +219,10 @@
         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)
+        maxmetric=$(ip route show $phys_otheraddr/$phys_mask | grep -v "dev $virt " | sed -e 's/^/0 /' -e 's/.*metric \([0-9]\+\)/\1/' -e 's/^\([0-9]\+\).*/\1/' | 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.
+                # If there are other routes that match this spec 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