[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