[Openswan dev] [PATCH V2] Incorrect automatic route via ipsec0
Roel van Meer
rolek at bokxing.nl
Wed Oct 20 05:06:49 EDT 2010
Roel van Meer writes:
> The full explanation:
>
> When openswan starts with klips, it creates an ipsec device and it assignes
> the same ip addresses to this device as are present on the physical device.
> Normally, this leaves you with two routes to the locally connected network,
> like so:
>
> 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
>
> (This is assuming you do not have tunnel definitions for 1.2.3.0/24 and your
> default gateway is a host in 1.2.3.0/24.)
>
> Normal linux kernel uses the first installed route to a given host. This
> will be the route through the physical device. This way, traffic to hosts on
> this network are routed via the physical link, which is correct, since it
> has nothing to do with openswan (there are no tunnel definitions for it).
>
> Now, with Julian Anastasov's alternative-routing patches, the route
> selection process changes. The order in which the routes are installed is no
> longer the key factor. So, after setting up the ipsec0 device, we now have
> two routes which are both valid candidates. When the kernel queries the
> routing tables for a route to a host on 1.2.3.0/24, it now gets a route
> through the _virtual_ device. This causes this traffic to be dropped.
>
> There are several workarounds for this issue:
>
> - Assign the ip addresses of the physical device to the virtual device with
> a netmask of /32. This avoids installing the local link routes via ipsec0.
The attached two patches apply this solution. One is for _startklips of
openswan 2.6.31, the other for the _startklips.in file Paul sent to the dev
list yesterday.
I've tested them both with openswan 2.6.31.
Patch description:
---/---
When openswan is used with klips, it creates a virtual device at startup.
The virtual device is associated with a physical device and the ip addresses
present on the physical device are also assigned to the virtual device. By
assigning these ip addresses to the virtual device with the same netmasks as
they have on the physical device, routes for locally connected networks are
created through the virtual device. In most setups, these routes are never
used, since the route through the physical device takes precedence because
it was installed earlier.
However, in some setups, the route through the virtual device would take
precedence, breaking connectivity to these networks. This happens with
Ubuntu 10.04, which has non-zero-metric routes and when using Julian
Anastasov's routing patches.
Avoid creating these routes by assigning ip addresses to the virtual device
with a netmask of /32 (for ipv4) or /128 (for ipv6).
This also means the ubuntu route metric fix is no longer necessary.
---/---
Regards,
roel
-------------- next part --------------
When openswan is used with klips, it creates a virtual device at startup.
The virtual device is associated with a physical device and the ip addresses
present on the physical device are also assigned to the virtual device.
By assigning these ip addresses to the virtual device with the same netmasks
as they have on the physical device, routes for locally connected networks are
created through the virtual device. In most setups, these routes are never
used, since the route through the physical device takes precedence because it
was installed earlier.
However, in some setups, the route through the virtual device would take
precedence, breaking connectivity to these networks. This happens with
Ubuntu 10.04, which has non-zero-metric routes and when using Julian
Anastasov's routing patches.
Avoid creating these routes by assigning ip addresses to the virtual device
with a netmask of /32 (for ipv4) or /128 (for ipv6).
This also means the ubuntu route metric fix is no longer necessary.
diff -ruN openswan-2.6.31.a/programs/_startklips/_startklips.in openswan-2.6.31.b/programs/_startklips/_startklips.in
--- openswan-2.6.31.a/programs/_startklips/_startklips.in 2010-10-18 18:13:36.000000000 +0200
+++ openswan-2.6.31.b/programs/_startklips/_startklips.in 2010-10-20 10:22:13.000000000 +0200
@@ -216,18 +216,7 @@
fi
# 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
+ ifconfig $virt inet $phys_addr $phys_type $phys_otheraddr netmask 255.255.255.255 mtu $phys_mtu
# Double check the mtu is not 0 - if it is set it to a saner default
ip link show dev $virt | grep -q 'mtu 0 '
-------------- next part --------------
When openswan is used with klips, it creates a virtual device at startup.
The virtual device is associated with a physical device and the ip addresses
present on the physical device are also assigned to the virtual device.
By assigning these ip addresses to the virtual device with the same netmasks
as they have on the physical device, routes for locally connected networks are
created through the virtual device. In most setups, these routes are never
used, since the route through the physical device takes precedence because it
was installed earlier.
However, in some setups, the route through the virtual device would take
precedence, breaking connectivity to these networks. This happens with
Ubuntu 10.04, which has non-zero-metric routes and when using Julian
Anastasov's routing patches.
Avoid creating these routes by assigning ip addresses to the virtual device
with a netmask of /32 (for ipv4) or /128 (for ipv6).
This also means the ubuntu route metric fix is no longer necessary.
--- _startklips.in.a 2010-10-20 10:31:14.000000000 +0200
+++ _startklips.in.b 2010-10-20 10:40:19.000000000 +0200
@@ -216,7 +216,10 @@
# configure all the IPv4/IPv6 addresses (including point-to-point)
ip addr show dev $phys | awk '$1 == "inet" || $1 == "inet6" {
cmd = "ip addr add"
- for (i = 2; i < NF; i++)
+ addr=$2
+ sub("/.*$","",addr)
+ cmd = cmd " " addr
+ for (i = 3; i < NF; i++)
cmd = cmd " " $i
if ($NF != phys)
cmd = cmd " " $NF
@@ -226,17 +229,6 @@
ip link set up dev $virt
fi
- # do we have to fix the route metric for this device?
- maxmetric=$(ip route show $phys_otheraddr/$phys_mask 2> /dev/null | 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
-
# Double check the mtu is not 0 - if it is set it to a saner default
ip link show dev $virt | grep -q 'mtu 0 '
RETVAL=$?
More information about the Dev
mailing list