[Openswan dev] openswan cisco interop patches
paul at xelerance.com
Mon Jul 11 12:38:16 EDT 2011
On Mon, 11 Jul 2011, Avesh Agarwal wrote:
> I am attaching a patch that addresses following issues:
I am replying to dev at openswan.org because I'd like more eyeballs to look at
> 1. Openswan "leftsourceip" breakage when using cisco remote ip address
> (related to #709273): Previously, the use of PLUTO_MY_SOURCEIP (intended
> upstream design of internal ip address required for communication between 2
> gateways) conflicted with the remote ip address provided by Cisco VPN
> concentrators as it required adding/deleting ip address with the connection
> establishment/termination, and it broke leftsourceip/rightsourceip. This
> patch tries to resolve this issue by adding/deleting cisco remote ip address
> only if remote_peer_type is set. So it will leave the upstream intended
> design unaffected while at the same time allowing for cisco provided remote
> ip address. I would appreciate any feedback on this.
I am a little worried with the downrule addition, because on a subnet-subnet
with leftsourceip= specified (to force gateway-gateway- to use internal IPs
and thus go via the tunnel) it should NOT be deleted when the connection goes
down or else the gateway loses its internal ip.
Best would be some kind of mechanism where we only delete IPs that we have
added before, though this means storing the IPs somewhere in pluto.
> 2. Openswan cisco connection issue (related to #704118): My testing showed
> that after an old cisco connection is terminated and a new connection is
> established (not related to rekey), cisco connection was retaining the old
> values causing addresses build up. The attached patch resolves this issue and
> now the connections can be established correctly by clearing old values.
Exposing delete_sr() also worries me a little, as it has been only called before
in the context of delete_connection() which does maintenance on linked lists.
Why are we not starting a new instance and deleting the old instance? That's
the behaviour I would expect if it is not a rekey.
More information about the Dev