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

Harald Jenny harald at a-little-linux-box.at
Wed Oct 20 10:21:04 EDT 2010

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:
> dev eth1 proto kernel scope link src 
> dev ipsec0 proto kernel scope link src 
> (This is assuming you do not have tunnel definitions for and your 
> default gateway is a host in
> 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, 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 <->, or even a 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

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

More information about the Dev mailing list