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

[Harald Jenny]

On Wed, Oct 20, 2010 at 10:06:24AM +0200, Roel van Meer wrote:
> 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.

I guess as both play with routing this shouldn't come unexpected...

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

Hmmm if we are only using this for sourceip than this may be a solution
(setting up routing with sourceip instead of the whole network).

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

Regarding the Ubuntu case also a good idea.

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

Hmmm good point.

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

Could anybody shed light on this?

> 
> Regards,
> 
> roel

Kind regards
Harald

> 
> _______________________________________________
> Dev mailing list
> Dev at openswan.org
> http://lists.openswan.org/mailman/listinfo/dev