[Openswan dev] [PATCH] Incorrect automatic route via ipsec0
Roel van Meer
rolek at bokxing.nl
Wed Oct 20 04:06:24 EDT 2010
Paul Wouters writes:
> On Wed, 20 Oct 2010, Roel van Meer wrote:
>> 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.
> Ahh yes. that would be good to know.
Well, it's those patches don't play nice with openswan. Or vise
versa. Without them, things behave like expected.
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,
18.104.22.168/24 dev eth1 proto kernel scope link src 22.214.171.124
126.96.36.199/24 dev ipsec0 proto kernel scope link src 188.8.131.52
(This is assuming you do not have tunnel definitions for 184.108.40.206/24 and your
default gateway is a host in 220.127.116.11/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 18.104.22.168/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.
- Assign the ip addresses of the physical device to the virtual device, but
change the metric of the created routes to one higher than the original ones
(this is the solution for the ubuntu issues). This causes the system to
prefer the route through the physical device.
>> 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
> it depends on sourceip= and/or subnets= options.
> eg imagine 22.214.171.124/24 <-> 126.96.36.199/24, or even a 0.0.0.0/0 subnet.
I see, but then the routes would be installed as part of the tunnel
management process, not as part of setting up ipsec0, is that correct?
I'm talking here about routes for networks not in any tunnel definition.
I still think that if I start openswan with klips (setting up ipsec0) with
no tunnels, I should get no routes through ipsec0. Is this correct? If not,
could you explain?
And a very much related question: why is the virtual device (ipsec)
configured with the exact same ip config as the physical device? I'd think
that assigning the ip addresses with a /32 netmask would suffice? You don't
need or use the routes you get when assigning the ip addresses with the same
netmasks and they (the routes) can only break things (as seen by the ubuntu
issue and the issue at hand).
More information about the Dev