[strongSwan] Aggressive Mode. Rekeying fails
Gerald Richter - ECOS
richter at ecos.de
Wed Mar 27 15:50:38 CET 2013
Hi,
when strongswan does not delete the IKE_SA too early, the IKE rekeying succeeds, but then then first phase 2 rekeying loses it's own ip address, so while the tunnel is still up, no traffic goes through anymore. The log looks like the following (with some added debug output). May you have an idea how to make strongswan keep it's own traffic selector instead of setting it to 0/0. You can see that when the QUICK_MODE request comes in, there is an traffic selector for the strongswan side, but in the function add_ts it has gone lost.
Note for getting this to work, I had to prohibit the mode_config request during the IKE rekeying, because the Cisco side doesn't answer this mode_config request (it does only answer during the initial contact to the mode_config).
Any idea how to fix this?
Thanks & Regards
Gerald
Mar 22 13:04:08 ThinClient charon: 04[ENC] parsed QUICK_MODE request 3835712975 [ HASH SA No ID ID ]
Mar 22 13:04:08 ThinClient charon: 04[IKE] get_ts: peer selected traffic selectors: 0.0.0.0/0 for (null), 192.168.104.14/32 for (null)
Mar 22 13:04:08 ThinClient charon: 04[CFG] looking for a child config for 192.168.104.14/32 === 0.0.0.0/0
Mar 22 13:04:08 ThinClient charon: 04[CFG] proposing traffic selectors for us:
Mar 22 13:04:08 ThinClient charon: 04[CFG] 192.168.104.14/32
Mar 22 13:04:08 ThinClient charon: 04[CFG] proposing traffic selectors for other:
Mar 22 13:04:08 ThinClient charon: 04[CFG] 0.0.0.0/0
Mar 22 13:04:08 ThinClient charon: 04[CFG] candidate "iaggr_vvph" with prio 5+5
Mar 22 13:04:08 ThinClient charon: 04[CFG] found matching child config "iaggr_vvph" with prio 10
Mar 22 13:04:08 ThinClient charon: 04[CFG] selecting traffic selectors for other:
Mar 22 13:04:08 ThinClient charon: 04[CFG] config: 0.0.0.0/0, received: 0.0.0.0/0 => match: 0.0.0.0/0
Mar 22 13:04:08 ThinClient charon: 04[IKE] select_ts: local=0 ts=0.0.0.0/0
Mar 22 13:04:08 ThinClient charon: 04[CFG] selecting traffic selectors for us:
Mar 22 13:04:08 ThinClient charon: 04[CFG] config: 192.168.104.14/32, received: 192.168.104.14/32 => match: 192.168.104.14/32
Mar 22 13:04:08 ThinClient charon: 04[IKE] select_ts: local=1 ts=192.168.104.14/32
Mar 22 13:04:08 ThinClient charon: 04[CFG] selecting proposal:
Mar 22 13:04:08 ThinClient charon: 04[CFG] proposal matches
Mar 22 13:04:08 ThinClient charon: 04[CFG] received proposals: ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ
Mar 22 13:04:08 ThinClient charon: 04[CFG] configured proposals: ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ, ESP:3DES_CBC/HMAC_SHA1_96/NO_EXT_SEQ, ESP:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/BLOWFISH_CBC_256/HMAC_SHA1_96
Mar 22 13:04:08 ThinClient charon: 04[CFG] selected proposal: ESP:AES_CBC_256/HMAC_MD5_96/NO_EXT_SEQ
Mar 22 13:04:08 ThinClient charon: 04[IKE] received 300s lifetime, configured 28800s
Mar 22 13:04:08 ThinClient charon: 04[IKE] received 4608000000 lifebytes, configured 0
Mar 22 13:04:08 ThinClient charon: 04[IKE] check_for_rekeyed_child child_sa state=INSTALLED name=iaggr_vvph config name=iaggr_vvph
Mar 22 13:04:08 ThinClient charon: 04[IKE] check_for_rekeyed_child -> check policies
Mar 22 13:04:08 ThinClient charon: 04[IKE] check_for_rekeyed_child local eq = yes remote eq = yes proposal eq =yes
Mar 22 13:04:08 ThinClient charon: 04[IKE] detected rekeying of CHILD_SA iaggr_vvph{3}
Mar 22 13:04:08 ThinClient charon: 04[ENC] added payload of type SECURITY_ASSOCIATION_V1 to message
Mar 22 13:04:08 ThinClient charon: 04[ENC] added payload of type NONCE_V1 to message
Mar 22 13:04:08 ThinClient charon: 04[IKE] add_ts: hsi ::/0[0] hsr ::/0[0]
Mar 22 13:04:08 ThinClient charon: 04[IKE] add_ts add to message: hsi ::/0[0] this->tsi 0.0.0.0/0 hsr ::/0[0] this->tsr 192.168.104.14/32
> -----Ursprüngliche Nachricht-----
> Von: users-bounces+richter=ecos.de at lists.strongswan.org [mailto:users-
> bounces+richter=ecos.de at lists.strongswan.org] Im Auftrag von Gerald
> Richter - ECOS
> Gesendet: Mittwoch, 20. März 2013 15:59
> An: Martin Willi
> Cc: users at lists.strongswan.org
> Betreff: Re: [strongSwan] Aggressive Mode. Rekeying fails
>
> 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
>
>
>
> _______________________________________________
> Users mailing list
> Users at lists.strongswan.org
> https://lists.strongswan.org/mailman/listinfo/users
More information about the Users
mailing list