StrongSWAN is one of the best solutions for IPSec VPN on VMs, it is extremely flexible and support multi-protocols as well as varies Auth methods.
Recently I set up a conn that support IPSec on Mac/iOS platform using XAuth, which looks like that:

conn android_xauth_psk
    keyexchange=ikev1
    left=%defaultroute
    leftauth=psk
    leftsubnet=0.0.0.0/0
    right=%any
    rightauth=psk
    rightauth2=xauth
    rightsourceip=10.31.2.0/24
    auto=add

Credit: one-key-ipsec project on github by quericy

We observed that on iOS side the rekey process initiated by StrongSWAN server will fail and, therefore, the VPN connection will down.

According to StrongSWAN:

When MOBIKE and DPD are enabled, charon piggybacks NAT-D notifications onto the DPD messages (empty informationals). iOS 9 and 10 do not respond to such messages.
This causes charon to regard the peer as unreachable and trigger the dpdaction. This can cause charon to delete the IKE_SA and associated CHILD_SA, therefore closing the tunnel.

Available workarounds are to disable either DPD or MOBIKE by using mobike=no or dpdaction=none.
If dpd is disabled, an unreachable peer is not detected as such until it reconnects and the uniqueness policy (uniqueids in ipsec.conf, connections..unique in swanctl.conf) is set to replace the old connection of an identity with the new connection.

If an unreachable peer is not detected and a roadwarrior connection with a virtual IP pool is used, the pool will inadvertently fill up.

If mobike is disabled, the roaming experience of a peer can suffer.

StrongSWAN says this problem is fixed in the 2126-mobike-dpd branch in the git repository and in version 5.5.1 and later. However, I can still see this problem even if my StrongSWAN version is U5.5.1/K3.13.0-24-generic.

StrongSWAN suggests that if this bug is triggered, you can always set mobike=no or dpdaction=none. By disabling one of the two features, the rekey process will pass through.

However, this kind of solution sacrifices some of the very important features of IPSec VPN. They are not considered good solutions for me.

There is another solution is to add more time to the lifetime or modify some other parameters that contribute to the calculation of the rekey time:

rekeytime = lifetime - (margintime + random(0, margintime * rekeyfuzz))

That will work, however, it will not solve the problem because the rekey time will finally come and the connection will be down by then.

What should we do then? There is one tricky way to do that is by setting rekey=no. If you require a secure connection, you would not want to do that. However, for test purpose, I disabled rekey on server side manually.

This is what I get after several hours (See the log at the very end of the article):
The basic idea is the server will not initiate any rekey process anymore and will not issue a new key at anytime anymore. However, at the same time, the iOS end will get bored of the key he is using forever, so he will do a [make-before-break reauthentication]. This method first creates duplicates of the IKE SA and then deletes the old ones at the same time IPsec SAs are adopted by the new IKE SA and not recreated. This avoids interruptions but requires that both peers can handle overlapping SAs (e.g. in regards to virtual IPs, duplicate policies or updown scripts).

Sep 19 05:21:39 localhost charon: 10[NET] received packet: from CLIENT_IP[27786] to SERVER_IP[4500] (848 bytes)
Sep 19 05:21:39 localhost charon: 10[ENC] parsed ID_PROT request 0 [ SA V V V V V V V V V V V V V V ]
Sep 19 05:21:39 localhost charon: 10[IKE] received NAT-T (RFC 3947) vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-08 vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-07 vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-06 vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-05 vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-04 vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-03 vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-02 vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received XAuth vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received Cisco Unity vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received FRAGMENTATION vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] received DPD vendor ID
Sep 19 05:21:39 localhost charon: 10[IKE] CLIENT_IP is initiating a Main Mode IKE_SA
Sep 19 05:21:39 localhost charon: 10[ENC] generating ID_PROT response 0 [ SA V V V V ]
Sep 19 05:21:39 localhost charon: 10[NET] sending packet: from SERVER_IP[4500] to CLIENT_IP[27786] (160 bytes)
Sep 19 05:21:39 localhost charon: 10[NET] received packet: from CLIENT_IP[27786] to SERVER_IP[4500] (380 bytes)
Sep 19 05:21:39 localhost charon: 10[ENC] parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
Sep 19 05:21:39 localhost charon: 10[IKE] remote host is behind NAT
Sep 19 05:21:39 localhost charon: 10[ENC] generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
Sep 19 05:21:39 localhost charon: 10[NET] sending packet: from SERVER_IP[4500] to CLIENT_IP[27786] (396 bytes)
Sep 19 05:21:40 localhost charon: 12[NET] received packet: from CLIENT_IP[27786] to SERVER_IP[4500] (300 bytes)
Sep 19 05:21:40 localhost charon: 12[ENC] parsed QUICK_MODE request 2904801601 [ HASH SA No ID ID ]
Sep 19 05:21:40 localhost charon: 12[IKE] received 3600s lifetime, configured 0s
Sep 19 05:21:40 localhost charon: 12[IKE] detected rekeying of CHILD_SA android_xauth_psk{3}
Sep 19 05:21:40 localhost charon: 12[ENC] generating QUICK_MODE response 2904801601 [ HASH SA No ID ID ]
Sep 19 05:21:40 localhost charon: 12[NET] sending packet: from SERVER_IP[4500] to CLIENT_IP[27786] (188 bytes)
Sep 19 05:21:40 localhost charon: 13[NET] received packet: from CLIENT_IP[27786] to SERVER_IP[4500] (92 bytes)
Sep 19 05:21:40 localhost charon: 13[ENC] parsed ID_PROT request 0 [ ID HASH ]
Sep 19 05:21:40 localhost charon: 13[CFG] looking for XAuthInitPSK peer configs matching SERVER_IP...CLIENT_IP[192.168.12.105]
Sep 19 05:21:40 localhost charon: 13[CFG] selected peer config "android_xauth_psk"
Sep 19 05:21:40 localhost charon: 13[ENC] generating ID_PROT response 0 [ ID HASH ]
Sep 19 05:21:40 localhost charon: 13[NET] sending packet: from SERVER_IP[4500] to CLIENT_IP[27786] (92 bytes)
Sep 19 05:21:40 localhost charon: 13[ENC] generating TRANSACTION request 2645642905 [ HASH CPRQ(X_USER X_PWD) ]
Sep 19 05:21:40 localhost charon: 13[NET] sending packet: from SERVER_IP[4500] to CLIENT_IP[27786] (92 bytes)
Sep 19 05:21:40 localhost charon: 16[NET] received packet: from CLIENT_IP[27786] to SERVER_IP[4500] (76 bytes)
Sep 19 05:21:40 localhost charon: 16[ENC] parsed QUICK_MODE request 2904801601 [ HASH ]
Sep 19 05:21:40 localhost charon: 16[IKE] CHILD_SA android_xauth_psk{4} established with SPIs c38738dc_i 0f5d4ca8_o and TS 0.0.0.0/0 === 10.31.2.1/32
Sep 19 05:21:40 localhost charon: 14[NET] received packet: from CLIENT_IP[27786] to SERVER_IP[4500] (108 bytes)
Sep 19 05:21:40 localhost charon: 14[ENC] parsed TRANSACTION response 2645642905 [ HASH CPRP(X_USER X_PWD) ]
Sep 19 05:21:40 localhost charon: 14[IKE] XAuth authentication of 'shanshan' successful
Sep 19 05:21:40 localhost charon: 14[ENC] generating TRANSACTION request 2950188283 [ HASH CPS(X_STATUS) ]
Sep 19 05:21:40 localhost charon: 14[NET] sending packet: from SERVER_IP[4500] to CLIENT_IP[27786] (92 bytes)
Sep 19 05:21:40 localhost charon: 15[NET] received packet: from CLIENT_IP[27786] to SERVER_IP[4500] (92 bytes)
Sep 19 05:21:40 localhost charon: 15[ENC] parsed TRANSACTION response 2950188283 [ HASH CPA(X_STATUS) ]
Sep 19 05:21:40 localhost charon: 15[IKE] IKE_SA android_xauth_psk[4] established between SERVER_IP[SERVER_IP]...CLIENT_IP[192.168.12.105]
Sep 19 05:21:40 localhost charon: 15[IKE] detected reauth of existing IKE_SA, adopting 2 children and 1 virtual IPs
Sep 19 05:21:45 localhost charon: 11[NET] received packet: from CLIENT_IP[27786] to SERVER_IP[4500] (108 bytes)
Sep 19 05:21:45 localhost charon: 11[ENC] parsed INFORMATIONAL_V1 request 3816651478 [ HASH D ]
Sep 19 05:21:45 localhost charon: 11[IKE] received DELETE for IKE_SA android_xauth_psk[3]
Sep 19 05:21:45 localhost charon: 11[IKE] deleting IKE_SA android_xauth_psk[3] between SERVER_IP[SERVER_IP]...CLIENT_IP[192.168.12.105]



This artical is created by Jialin with Attribution-NonCommercial-ShareAlike 4.0 International (CC BY-NC-SA 4.0) license.
知识共享许可协议