I'm running into some strange behavior with my Mac VPN - I'm wondering if anyone has run into this before. Is this a setting I can toggle somewhere in my VPN configuration, or should I submit a bug report for the behavior disparity?
I have a StrongSwan server running remotely and I'm connecting to it successfully from a VPN configuration on my Mac. I have recently tried using the "Connect on demand" feature to auto-connect my VPN, this works but I noticed that if my internet cuts out abruptly (e.g. just turn off wifi) then when the internet is back, my Mac is unable to resume the existing VPN session and must begin a new one. Without "Connect on demand", macOS is capable of resuming the existing VPN session upon reconnecting to the internet.
The VPN is using IKEv2 with certificate authentication. As an example of the difference, I run `tail -f /var/log/ipsec.log` on the server to view logs incoming as I toggle wifi off and back on.
Without "Connect on demand" (x.y.z.w is client, 1.2.3.4 is server), I get this after I toggle wifi off/on:
Feb 14 15:18:08 09[NET] <cert-config|3> received packet: from x.y.z.w[4500] to 1.2.3.4[4500] (140 bytes)
Feb 14 15:18:08 09[ENC] <cert-config|3> parsed INFORMATIONAL request 4 [ N(UPD_SA_ADDR) N(NATD_S_IP) N(NATD_D_IP) ]
Feb 14 15:18:08 09[ENC] <cert-config|3> generating INFORMATIONAL response 4 [ N(NATD_S_IP) N(NATD_D_IP) ]
Feb 14 15:18:08 09[NET] <cert-config|3> sending packet: from 1.2.3.4[4500] to x.y.z.w[4500] (124 bytes)
And this is all the traffic needed serverside to resume the VPN session on the Mac.
With "Connect on demand", I get this after I toggle wifi off/on:
Feb 14 15:19:11 07[NET] <6> received packet: from x.y.z.w[500] to 1.2.3.4[500] (432 bytes)
Feb 14 15:19:11 07[ENC] <6> parsed IKE_SA_INIT request 0 [ SA KE No N(REDIR_SUP) N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) ]
Feb 14 15:19:11 07[IKE] <6> x.y.z.w is initiating an IKE_SA
Feb 14 15:19:11 07[IKE] <6> remote host is behind NAT
Feb 14 15:19:11 07[ENC] <6> generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(MULT_AUTH) ]
Feb 14 15:19:11 07[NET] <6> sending packet: from 1.2.3.4[500] to x.y.z.w[500] (440 bytes)
Feb 14 15:19:11 10[NET] <6> received packet: from x.y.z.w[4500] to 1.2.3.4[4500] (1388 bytes)
Feb 14 15:19:11 10[ENC] <6> parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) N(MOBIKE_SUP) IDr AUTH CERT CPRQ(ADDR DHCP DNS MASK ADDR6 DHCP6 DNS6) N(ESP_TFC_PAD_N) N(NON_FIRST_FRAG) SA TSi TSr ]
..................... (authentication stuff)......
Feb 14 15:19:12 10[ENC] <cert-config|6> generating IKE_AUTH response 1 [ IDr CERT CERT AUTH CPRP(ADDR DNS) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
Feb 14 15:19:12 10[NET] <cert-config|6> sending packet: from 1.2.3.4[4500] to x.y.z.w[4500] (3036 bytes)
In other words, we can see the Mac VPN client is generate a new IKE_SA_INIT rather than resuming the old session with an informational request. This is a little annoying for me because my server keeps around the old SA for about an hour waiting to reconnect, so if my internet connectivity is weak then it ends up with a bunch of these.
Here's the XML configuring my on-demand connection. It checks a URL and connects if that URL gives a 200 response.
<key>OnDemandEnabled</key>
<integer>1</integer>
<key>OnDemandRules</key>
<array>
<dict>
<key>Action</key>
<string>Connect</string>
<key>URLStringProbe</key>
<string>(URL_REMOVED)</string>
</dict>
<dict>
<key>Action</key>
<string>Disconnect</string>
</dict>
</array>