[strongSwan-dev] Regarding missbehaviour of strongswan4.5.3 while mix configuration of ikev1 and sec-gw ikev2

[Amit Kumar]

Hi,

We are using strongswan4.5.3 .

Configuration:
At our HW where strongswan is used
one bypass policy and another is protected which is any to any with ikev1.

Security g/w
Check point
For protected having both ikev1 and ikev2 for same policy

Scenario :

Initial it is established with ikev1 from the check point and work as per the expectation.

After some time later DPD restart has occured and check Point used to send IKE_SA_INIT from ikev2 and then association get established as our HW ikev1 and CP ikev2 as per the strongswan behavior.
Still it is able to accept ikev2. After some time later ikev1 used to send quick_mode to our HW and in Pluto logs I am able to see "pluto[4364]: | policy 0.0.0.0/0 === 0.0.0.0/0 in already exists, increasing refcount"

This is happened two times.

After some time the delete SA has come for charon
charon: 09[IKE] closing CHILD_SA conn1000{1} with SPIs c1a4906e_i (2209 bytes) 4ba2d472_o (9351 bytes) and TS 0.0.0.0/0 === 0.0L

Problem:
Policy has been deleted from xfrm, but still Pluto SAs is there and complete traffic used to stop due to there is no policy in the xfrm in our HW.

Can you please suggest how to handle this ?

As per my point of view it should not accept the ikev2 request, because there is no policy configured for ikev2 and if it is able to accept the request from ikev2 then it should check the existing plutos SA while deleting the policy when charon initiate closing SA.

Thanks in advance.


Thanks and best Regards,
Amit Kumar







===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================




===============================================================================
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===============================================================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/dev/attachments/20130906/24f07e39/attachment.html>