[strongSwan] Aggressive Mode. Rekeying fails

[Gerald Richter - ECOS]

Hi Martin,

I have done a lot of tests. What I see is that during rekeying the virtual ip gets deleted:

charon: 02[KNL] deleting virtual IP 192.168.104.12

Of course, no network traffic is going thru the tunnel anymore. The mode_config request coming later on, is not answered by the other side.

Anyway I think it's too early to drop the virtual ip, because also in case the mod_config request would give us a new ip, there is some time without ip address so the traffic would get interrupted.

I tried to fix this by coping over the virtual ip to the new ike state in adopt_children (in ike_sa_manage.c). I added:

	enumerator = old->create_virtual_ip_enumerator(old, TRUE);
	while (enumerator->enumerate(enumerator, &host))
	{	
		DBG2(DBG_IKE, "add old local virtual ip to new ike_sa");
		new->add_virtual_ip(new, TRUE, host) ;
	}
	enumerator->destroy(enumerator);

but this does not solved the problem. The virtual ip stays, but the traffic is still stopped as soon as the first ike is deleted.

Before the first rekey, sometime (not always) I see log lines like:

querying policy 0.0.0.0/0 === 192.168.104.12/32 in 
querying policy 0.0.0.0/0 === 192.168.104.12/32 fwd
querying policy 192.168.104.12/32 === 0.0.0.0/0 out

After the first rekey I only see the query for the out policy, in and fwd does not show up anymore.

My guess is that there needs to more things copied over form old to new ike, but I didn't find what it is. Maybe you can give me an insight...

Thanks & Regards

Gerald

> -----Ursprüngliche Nachricht-----
> Von: Martin Willi [mailto:martin at strongswan.org]
> Gesendet: Dienstag, 12. März 2013 10:09
> An: Gerald Richter - ECOS
> Cc: users at lists.strongswan.org
> Betreff: Re: AW: [strongSwan] Aggressive Mode. Rekeying fails
> 
> Hi Gerald,
> 
> > The IKE Rekeying succeeds, but afterwards it gets stuck within a
> > mode_config request. I don't think there should be a mode_config
> > request during rekeying or I am wrong?
> 
> strongSwan binds an INTERNAL_IPx_ADDRESS to the ISAKMP_SA, so it valid
> only during the lifetime of an ISAKMP_SA. This implies that IKE rekeying (or
> better, re-authentication) re-negotiates virtual IPs.
> 
> It is not fully clear to me what is the correct behavior, but
> draft-dukes-ike-mode-cfg-02 says:
> 
> > The requested address is valid until the expiry time defined with the
> > INTERNAL_ADDRESS EXPIRY attribute or until the ISAKMP SA that was used
> > to secure the request expires.
> 
> Regards
> Martin