[strongSwan] Aggressive Mode. Rekeying fails

[Gerald Richter - ECOS]

Hi,

I still trying to solve this issue...

I have tested an aggressive mode connection between two strongswan. That is working without problem.

Back the connection to Cisco ASA. In the Cisco Log I found the following message:

IKE SA being deleted during rekey before new SA active.
Removing TunnelTbl from tunnel table failed, no match!
sending delete/delete with reason message

Maybe the delete of the old IKE state (due to uniqueness policy) should be done after the IKE is fully established. At the moment it is done in the middle of the rekeying.

Any thoughts?

Regards

Gerald





> -----Ursprüngliche Nachricht-----
> Von: Gerald Richter Im Auftrag von Gerald Richter - ECOS
> Gesendet: Montag, 18. März 2013 15:28
> An: 'Martin Willi'
> Cc: 'users at lists.strongswan.org'
> Betreff: AW: AW: [strongSwan] Aggressive Mode. Rekeying fails
> 
> 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