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

[Roel van Meer]

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, 
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.
- 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
>> ipsec0?
> 
> it depends on sourceip= and/or subnets= options.
> 
> eg imagine 1.2.3.0/24 <-> 5.6.7.0/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).

Regards,

roel