[Openswan dev] [PATCH V2] Incorrect automatic route via ipsec0
Harald Jenny
harald at a-little-linux-box.at
Wed Oct 20 10:28:33 EDT 2010
On Wed, Oct 20, 2010 at 11:06:49AM +0200, Roel van Meer wrote:
> 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.
Hmm good idea alhough I'm asking myself if we could run into any problems...
>
> 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
Kind regards
Harald
> 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 '
> 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=$?
> _______________________________________________
> Dev mailing list
> Dev at openswan.org
> http://lists.openswan.org/mailman/listinfo/dev
More information about the Dev
mailing list