Project

General

Profile

Issue #2696

MAC verification failed - CREATE_CHILD_SA request processing failed for IOS RoadWarrior

Added by Scep CAfail almost 2 years ago. Updated almost 2 years ago.

Status:
Closed
Priority:
Normal
Category:
interoperability
Affected version:
5.6.2
Resolution:
No change required

Description

Hello,

Our following RoadWarrior setup is up and operational for multiple platforms.

Status of IKE charon daemon (strongSwan 5.6.2, Linux 4.4.0-1060-aws, x86_64):
  uptime: 11 days, since Jun 21 23:21:14 2018
  malloc: sbrk 2764800, mmap 0, used 742592, free 2022208
  worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 211
  loaded plugins: charon aes des rc2 sha2 sha1 md4 md5 mgf1 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp curve25519 xcbc cmac hmac sqlite attr attr-sql kernel-netlink resolve socket-default stroke vici updown eap-identity eap-sim eap-aka eap-aka-3gpp2 eap-simaka-pseudonym eap-simaka-reauth eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-peap eap-tnc xauth-generic xauth-eap tnc-tnccs radattr unity counters
Listening IP addresses:
  x.x.64.23
  x.x.64.139
Connections:
       IKEv2:  %any...%any  IKEv2
       IKEv2:   local:  [y.y.205.53] uses public key authentication
       IKEv2:    cert:  "our cert info" 
       IKEv2:   remote: uses EAP_RADIUS authentication with EAP identity '%any'
       IKEv2:   child:  0.0.0.0/0 === dynamic TUNNEL
conn %default
        ikelifetime=86400s
        auto=add
        leftfirewall=yes
        left=%any
        esp="aes128-sha-modp2048" 

conn IKEv2
        keyexchange=ikev2
        leftid=y.y.205.53
        leftcert=ourCert.der
        leftauth=pubkey
        leftsubnet=0.0.0.0/0
        lefthostaccess=no
        right=%any
        rightauth=eap-radius
        rightsourceip=%radius
        eap_identity=%identity

However for IOS clients, we get the following error after some time the client stays connected.

Security Associations (1 up, 0 connecting):
       IKEv2[300]: ESTABLISHED 27 minutes ago, x.x.64.23[y.y.205.53]...x.x.149.154[u158]
       IKEv2[300]: IKEv2 SPIs: 68cc9486e9b41d39_i 1eebba2d86bf389e_r*, public key reauthentication in 15 hours
       IKEv2[300]: IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
       IKEv2{389}:  INSTALLED, TUNNEL, reqid 190, ESP in UDP SPIs: c38b9ce2_i 01a13331_o
       IKEv2{389}:  AES_CBC_128/HMAC_SHA1_96/MODP_2048, 332 bytes_i (4 pkts, 166s ago), 0 bytes_o, rekeying in 44 minutes
       IKEv2{389}:   0.0.0.0/0 === x.x.245.158/32

It looks like rekeying is happening just fine for several times, but things go south after some time. Can't reason why the client is asking for the deletion of the SA it just rekeyed. Above example shows 27 minutes uptime but it is actually up longer than that (around 100 mins)

iosRekey.png (1.93 MB) iosRekey.png Scep CAfail, 03.07.2018 14:58

History

#1 Updated by Scep CAfail almost 2 years ago

The image showing the error doesn't seem to be embedded into the post using !!, please see the attached iosRekey.png

#2 Updated by Tobias Brunner almost 2 years ago

  • Status changed from New to Feedback

This looks strange, in particular because the log says that the failed message is a CREATE_CHILD_SA request with message ID 0, which can't really be on an IKE_SA that has been initiated by the peer (message IDs are increased sequentially and start with 0 for the IKE_SA_INIT, so a CREATE_CHILD_SA request by the initiator will at least have MID 2, if it was responder that could be different as each peer has its own MID counter - but if these were sent on the new IKE_SA it definitely was initiator). These are then followed by an INFORMATIONAL with ID 1, which seems a bit odd too because why would that get sent after failed retransmits of the other message.

You could try to change the log levels a bit (e.g. increase mgr to 2 to see which IKE_SA is checked out for a particular message).

Can't reason why the client is asking for the deletion of the SA it just rekeyed.

It doesn't, it deletes the IKE_SA that has been rekeyed (i.e. the old one) with unique ID 260, not the new one with unique ID 276.

Above example shows 27 minutes uptime but it is actually up longer than that (around 100 mins)

This only shows the uptime of that particular IKE_SA, if there were rekeyings before you won't see that here.

#3 Updated by Scep CAfail almost 2 years ago

Tobias Brunner wrote:

This looks strange, in particular because the log says that the failed message is a CREATE_CHILD_SA request with message ID 0, which can't really be on an IKE_SA that has been initiated by the peer (message IDs are increased sequentially and start with 0 for the IKE_SA_INIT, so a CREATE_CHILD_SA request by the initiator will at least have MID 2, if it was responder that could be different as each peer has its own MID counter - but if these were sent on the new IKE_SA it definitely was initiator). These are then followed by an INFORMATIONAL with ID 1, which seems a bit odd too because why would that get sent after failed retransmits of the other message.

You could try to change the log levels a bit (e.g. increase mgr to 2 to see which IKE_SA is checked out for a particular message).

Can't reason why the client is asking for the deletion of the SA it just rekeyed.

It doesn't, it deletes the IKE_SA that has been rekeyed (i.e. the old one) with unique ID 260, not the new one with unique ID 276.

Above example shows 27 minutes uptime but it is actually up longer than that (around 100 mins)

This only shows the uptime of that particular IKE_SA, if there were rekeyings before you won't see that here.

Thanks Tobias, I increased the log levels and waiting to reproduce.
I believe this may have something to do with the IOS endpoint going to screen-lock/sleep. I am informed that there were no disconnects 8 hours straight when the phone was kept open. However waking up after 30mins-1hour sleep/screen-lock, this issue was observed. Perhaps IOS is losing track of some essential state like counters during sleep.

#4 Updated by Scep CAfail almost 2 years ago

We are convinced that this is IOS related, you can close the case.
Thanks!

#5 Updated by Tobias Brunner almost 2 years ago

  • Status changed from Feedback to Closed
  • Assignee set to Tobias Brunner
  • Resolution set to No change required

We are convinced that this is IOS related, you can close the case.

OK. Could you provide any details?

#6 Updated by Scep CAfail almost 2 years ago

Tobias Brunner wrote:

We are convinced that this is IOS related, you can close the case.

OK. Could you provide any details?

The dev team didn't want to perform the tests again until they hear from Apple. Will update you if they get anything.

Also available in: Atom PDF