[strongSwan] charon not sending DELETE payload

[Gupta, Rohan 1. (NSN - IN/Bangalore)]

The problem seems to be solved now. Thank you for your help.

Thanks,
Rohan


-----Original Message-----
From: ext Andreas Steffen [mailto:andreas.steffen at strongswan.org] 
Sent: Wednesday, April 02, 2014 3:24 PM
To: Gupta, Rohan 1. (NSN - IN/Bangalore); users at lists.strongswan.org
Subject: Re: [strongSwan] charon not sending DELETE payload

As indicated in my last email

      sudo ipsec down <connection name>{<reqid>}

you can use the curly brackets to delete the CHILD_SA only while
keeping the IKE_SA. Thus

  ipsec down r1~v1{1}

deletes the CHILD_SA with reqid 1 whereas the wildcard

  ipsec down r1~v1{*}

deletes all CHILD_SAs for connection r1~v1 while keeping the IKE_SA[s].
The ipsec down syntax is defined in the ipsec man page

man ipsec
    down name
         tells the IKE daemon to terminate connection name.

    down name{n}
         terminates IKEv1 Quick Mode and IKEv2 CHILD SA instance n of 
connection name.

    down name{*}
         terminates all IKEv1 Quick Mode and  IKEv2 CHILD SA instances 
of connection name.

    down name[n]
         terminates IKE SA instance n of connection name.

    down name[*]
         terminates all IKE SA instances of connection name.

Regards

Andreas

On 02.04.2014 10:37, Gupta, Rohan 1. (NSN - IN/Bangalore) wrote:
> Hi,
>
> I tried using this command but the output suggests that Phase 1(IKE_SA) is also getting re-negotiated.
>
> Is it possible to use this command to trigger re-negotiation of phase-2(CHILD_SA) only?
>
> # ipsec down r1~v1
> deleting IKE_SA r1~v1[1] between 169.254.0.4[(vr*)169.254.0.4]...169.254.0.6[(vr*)169.254.0.6]
> sending DELETE for IKE_SA r1~v1[1]
> generating INFORMATIONAL request 0 [ D ]
> sending packet: from [500] to [500]
> received packet: from [500] to [500]
> parsed INFORMATIONAL response 0 [ ]
> IKE_SA deleted
>
> Thanks,
> Rohan
>
>
> -----Original Message-----
> From: ext Andreas Steffen [mailto:andreas.steffen at strongswan.org]
> Sent: Wednesday, April 02, 2014 1:00 PM
> To: Gupta, Rohan 1. (NSN - IN/Bangalore); users at lists.strongswan.org
> Subject: Re: [strongSwan] charon not sending DELETE payload
>
> Hi Gupta,
>
> if you are using the setkey command which is part of the ipsec-tools
> package to flush a CHILD_SA in the kernel then you cannot expect the
> strongSwan IKE daemon to take notice of this event. If you want
> an IKE DELETE notify message to be generated then you must take down
> the SA with the strongSwan command
>
>     sudo ipsec down <connection name>{<requid>}
>
> Best regards
>
> Andreas
>
> On 02.04.2014 08:57, Gupta, Rohan 1. (NSN - IN/Bangalore) wrote:
>> Hi,
>> Recently during my testing of charon with strongswan version 4.3.1, I
>> observed that after establishment of the tunnel if I flush the
>> child_sa(or the phase 2 SA's) using setkey -F the DELETE payload is not
>> sent to the peer.
>> Due to this the peer doesn't delete its child_sa and keeps on sending
>> traffic with the old SA.
>> I have gone through the RFC and found the flowing line
>> "/If an IKE endpoint chooses to/
>> /   delete CHILD_SAs, it MUST send Delete payloads to the other end/
>> /   notifying it of the deletion/"
>> Is the above statement applicable for this scenario?
>> Can anyone help on what might be wrong?
>> Thanks,
>> Rohan
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.strongswan.org
>> https://lists.strongswan.org/mailman/listinfo/users
>>
>

-- 
======================================================================
Andreas Steffen                         andreas.steffen at strongswan.org
strongSwan - the Open Source VPN Solution!          www.strongswan.org
Institute for Internet Technologies and Applications
University of Applied Sciences Rapperswil
CH-8640 Rapperswil (Switzerland)
===========================================================[ITA-HSR]==