[strongSwan] IKEv1 Phase 1 rekey deletes Phase 2 SAs

Sean B sb3957312 at gmail.com
Tue Mar 9 17:50:44 CET 2021


Hi Strongswan-users,

I have a set up that requires IKEv1 and I'm running into a problem when the
IKEv1 Phase 1 (IKE SA) rekeys.  Phase 1 appears to rekey correctly, but
deletes the Phase 2 SAs.
Based on the following website, IPsec SAs are supposed to be adopted by the
new IKE SA and not recreated:
https://wiki.strongswan.org/projects/strongswan/wiki/ExpiryRekey
*"IKEv1* SAs are also rekeyed/reauthenticated using a make-before-break
scheme, however, only the IKE SA is affected. IPsec SAs are adopted by the
new IKE SA and not recreated."

In this setup the Strongswan (192.19.22.10) is configured as the Responder
and a Cisco IOS (192.19.22.1) device as the Initiator.
The initial connection is established, and the traffic is sent ESP
encapsulated.  The initiator attempts to rekey the IKE SA, and appears to
succeed.
Both the Initiator and the Responder are shown with the new IKE SA SPIs,
but during the IKE SA rekey Strongswan deletes the SAD entries for the
IPsec SAs.

Can someone please assist with troubleshooting this issue?
I am unable to determine if this is due to a configuration with the
connections in ipsec.conf, a setting in charon.conf, or if this is an issue
with how Cisco IOS attempts to rekey IKE SAs.
Cisco appears to be sending a DELETE message as per
https://tools.ietf.org/html/draft-jenkins-ipsec-rekeying-06#section-3.2.

I've included the 'ipsec statusall' outputs, ipsec.conf, and
charon_debug.log
(I've added charon_debug.log as an attachment, would it have been better to
copy and paste into the body of the email?)
#####
# ipsec.conf - strongSwan IPsec configuration file

# basic configuration
config setup
    # strictcrlpolicy=yes
    # uniqueids = no

# Add connections here.
conn VPNPeer
        leftfirewall=yes
        keyexchange=ikev1

        # Phase 1 settings
        ikelifetime=24h
        margintime=0
        rekeyfuzz=0%
        lifetime=8h
        ike=aes256-sha1-modp2048 !

        # Phase 2
        esp=aes128-sha1-modp2048 !

        left=192.19.22.10
        right=192.19.22.1

        authby=psk

        type=tunnel

        auto=add

        # Rekeying
        #rekey=no

include /var/lib/strongswan/ipsec.conf.inc


#####
Here are the results from 'ipsec statusall':
Initial connection:
#ipsec statusall

Status of IKE charon daemon (weakSwan 5.8.4, Linux 5.5.0-kali2-amd64,
x86_64):
  uptime: 20 seconds, since Mar 09 13:32:08 2021
  malloc: sbrk 1622016, mmap 0, used 610688, free 1011328
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
scheduled: 3
  loaded plugins: charon aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509
revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey
pem openssl fips-prf gmp agent xcbc hmac gcm drbg attr kernel-netlink
resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic
counters

Listening IP addresses:
  192.19.22.10
  172.19.22.10
  172.17.0.1
Connections:
     VPNPeer:  192.19.22.10...192.19.22.1  IKEv1
     VPNPeer:   local:  [192.19.22.10] uses pre-shared key authentication
     VPNPeer:   remote: [192.19.22.1] uses pre-shared key authentication
     VPNPeer:   child:  dynamic === dynamic TUNNEL

Security Associations (1 up, 0 connecting):
     VPNPeer[1]: ESTABLISHED 11 seconds ago,
192.19.22.10[192.19.22.10]...192.19.22.1[192.19.22.1]
     VPNPeer[1]: IKEv1 SPIs: e53ec81750a41b9c_i 84f72669eb1b150b_r*,
pre-shared key reauthentication in 23 hours
     VPNPeer[1]: IKE proposal:
AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
     VPNPeer{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c8bf9eca_i
2d5a8f29_o
     VPNPeer{1}:  AES_CBC_128/HMAC_SHA1_96/MODP_2048, 400 bytes_i (4 pkts,
9s ago), 400 bytes_o (4 pkts, 9s ago), rekeying in 7 hours
     VPNPeer{1}:   192.19.22.10/32 === 192.19.22.1/32



After IKE Phase 1 rekey:
#ipsec statusall

Status of IKE charon daemon (weakSwan 5.8.4, Linux 5.5.0-kali2-amd64,
x86_64):
  uptime: 6 minutes, since Mar 09 13:32:08 2021
  malloc: sbrk 1622016, mmap 0, used 640656, free 981360
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
scheduled: 5
  loaded plugins: charon aesni aes rc2 sha2 sha1 md5 mgf1 random nonce x509
revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey
pem openssl fips-prf gmp agent xcbc hmac gcm drbg attr kernel-netlink
resolve socket-default connmark stroke updown eap-mschapv2 xauth-generic
counters

Listening IP addresses:
  192.19.22.10
  172.19.22.10
  172.17.0.1
Connections:
     VPNPeer:  192.19.22.10...192.19.22.1  IKEv1
     VPNPeer:   local:  [192.19.22.10] uses pre-shared key authentication
     VPNPeer:   remote: [192.19.22.1] uses pre-shared key authentication
     VPNPeer:   child:  dynamic === dynamic TUNNEL

Security Associations (1 up, 0 connecting):
     VPNPeer[2]: ESTABLISHED 9 seconds ago,
192.19.22.10[192.19.22.10]...192.19.22.1[192.19.22.1]
     VPNPeer[2]: IKEv1 SPIs: e53ec81702d2cc91_i 47da289647a60462_r*,
pre-shared key reauthentication in 23 hours
     VPNPeer[2]: IKE proposal:
AES_CBC_256/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048

#####
# charon_debug.log - attached.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.strongswan.org/pipermail/users/attachments/20210309/4c35ad50/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: charon_debug.log
Type: application/octet-stream
Size: 28985 bytes
Desc: not available
URL: <http://lists.strongswan.org/pipermail/users/attachments/20210309/4c35ad50/attachment-0001.obj>


More information about the Users mailing list