[Openswan dev] [PATCH] Incorrect automatic route via ipsec0
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:
> 188.8.131.52/24 dev eth1 proto kernel scope link src 184.108.40.206
> 220.127.116.11/24 dev ipsec0 proto kernel scope link src 18.104.22.168
> (This is assuming you do not have tunnel definitions for 22.214.171.124/24 and your
> default gateway is a host in 126.96.36.199/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 188.8.131.52/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 184.108.40.206/24 <-> 220.127.116.11/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?
> Dev mailing list
> Dev at openswan.org
More information about the Dev