[Openswan Users] redundant ipsec connections: route to peer's client conflicts with ... relesing old connection to free the route

Paul Wouters paul at xelerance.com
Thu Jun 4 15:45:34 EDT 2009


On Thu, 4 Jun 2009, Oguz Yilmaz wrote:

> My aim is not high availability in the center. I am OK with single
> Central server. Lets concentrate ont he peer. Peer has 2 internet
> access. 2 of VPN s will work on the first access line and 1 of VPNs
> will work on the second access line.
>
> At the moment ip xfrm policy:
>
> src 172.17.0.0/24 dst 172.19.0.0/24
>        dir out priority 2344
>        tmpl src CENTRALIPADDR dst PEERDSL1
>                proto esp reqid 16397 mode tunnel
> src 172.16.0.0/24 dst 172.19.0.0/24
>        dir out priority 2344
>        tmpl src CENTRALIPADDR  dst PEERDSL2
>                proto esp reqid 16401 mode tunnel
> src 10.0.0.0/8 dst 172.19.0.0/24
>        dir out priority 2856
>        tmpl src CENTRALIPADDR dst PEERDSL2
>                proto esp reqid 16405 mode tunnel

Ahh, i understand now.

> What I want is establishing this state quickly. At the moment it takes
> about 5-15 minutes. As you can see policy does not overlap actually.
> Sources are different for each. The problem is I think openswan only
> look for the destinaiton for preventing routing overlapping.
>
> How can I disable checking routings and releasing old connection to
> free the route?

Probably somewhere in programs/pluto/kernel.c or kernel_netlink.c. The
code should check, probably via new kernel_ops check, if the current
stack supports this situation, and then allow it for netkey, and disallow
it for klips.

For a more quick fix approach, you might want to specify a leftupdown=
and copy and modify the stock _updown script to add the appropriate
"ip rule" based routes.

Paul


More information about the Users mailing list