[Openswan dev] openswan cisco interop patches

[Avesh Agarwal]

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.

>
>> 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