[Openswan dev] openswan cisco interop patches

[Avesh Agarwal]

On 07/11/2011 12:38 PM, Paul Wouters wrote:
> 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
> this.
>
>> 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.
>
Yes, I have also targetted the same behavior. downrule is only delete an 
ipaddress when remote_peer_type (PLUTO_IS_PEER_CISCO) is true that means 
it does the same thing what you described.
>> 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.
I can explain it more to tell why it works this way: If you look at the 
code, received XAUTH parameters (ip address, domain, banner etc) are 
stored in connection definition not in state definition, and this 
behavior has been well before me. So when a connection/state terminates, 
the old values remains since connection is not being deleted only 
terminated. Therefore, it is needed to clear those values when a new IKE 
exchange is started as the new values of XAUTH parameters may be 
received. And I did not see any other way to handle this.

>
> Paul

-- 
Thanks and Regards
Avesh