[Openswan dev] openswan cisco interop patches

[Avesh Agarwal]

On 07/11/2011 01:42 PM, Avesh Agarwal wrote:
> On 07/11/2011 01:34 PM, Paul Wouters wrote:
>> On Mon, 11 Jul 2011, Avesh Agarwal wrote:
>>
>>>> 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.
>>
>> So if I mistakenly configure leftsourceip=ip_of_eth0 and 
>> remote_peer_type=cisco
>> and the connection comes up without getting an IP address from the 
>> remote, and
>> I bring the connection down, will I lose eth0 connectivity?
> I think that seems a wrong configuration because if 
> remote_peer_type=cisco is set, that openswan is acting as client and 
> an ip address will be obtained from the server. So this should not be 
> done in first place.
>
> However, even if it is done, it should be overwritten by the ip 
> addresss received from the server. But it is difficult to know if the 
> old address in the source ip field is from the old connection instance 
> or due to wrong connection definition by mistake as you said.
>
Wanted to add that i think, if we prevent of setting leftsourceip and 
remote_peer_type in the same connection definition, then it should 
resolve this issue.
>>
>>> 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.
>>
>> I see. So perhaps these parameters should move from connection to state?
>>
> This may be problem during rekey, when a new state instance is 
> created, and the xauth values from old state will get deleted.
>
>> But then if we are the server, they will appear in the config file 
>> and should
>> go into the connection information. 
> I agree, but the server side should not have an issue I think.
>> Hugh, how would you envision this should
>> be done? Do we have other occurances of server side variables in 
>> connection
>> with 'state' variables in the client instance?
>>
>> Paul


-- 
Thanks and Regards
Avesh