Sonoma bug: IKEv2 VPN no longer rekeys so VPN connections drop every 20-25 minutes.

[bogdanw]

MacOS let's me choose a Username + Password as Authentication for IKEv2, the iMazing-Profile-Editor does not list that option. What am I doing wrong?

“Set to None when enabling EAP (ExtendedAuthEnabled)”
So, set to None, then check Enable EAP-only authentication, username and password fields will become available.

May I ask for the path of the log(s) on MacOS that I can tail?

See post #12

 

[Mcrumors David]

“Set to None when enabling EAP (ExtendedAuthEnabled)”
So, set to None, then check Enable EAP-only authentication, username and password fields will become available.

See post #12

Appreciated. After trial and error I was able to inject a VPN profile created by Apple Configurator into my System Settings and successfully connect on Sonoma.

I tested it and it worked well passed the 24min mark (last time I checked it was active for 1h:20m).

...
Am I happy about it? No, on Ventura (basically every OS below Sonoma) I can simply use the System-Setting's VPN page and voilà ...

 

[cwagz78]

After upgrading to 14.2 my working VPN profile that had a username and password (shared key) embedded will no longer connect. If I create a profile with no preshared key, I can connect by entering the key when the pop up asks for it during connection. If I go into the macOS VPN settings and try to save the password, then the VPN profile will no longer connect no matter what I do. I have to remove the profile, reload it and enter the password each time I connect.

Anyone else experience this?

This is an IKEV2 EAP-MSCHAP VPN. Same profile I have been using for quite some time without issue until 14.2 came out.

 

[Mcrumors David]

After upgrading to 14.2 my working VPN profile that had a username and password (shared key) embedded will no longer connect. If I create a profile with no preshared key, I can connect by entering the key when the pop up asks for it during connection. If I go into the macOS VPN settings and try to save the password, then the VPN profile will no longer connect no matter what I do. I have to remove the profile, reload it and enter the password each time I connect.

Anyone else experience this?

This is an IKEV2 EAP-MSCHAP VPN. Same profile I have been using for quite some time without issue until 14.2 came out.

What does the server side look like?

Any logs?

*Better post on the Apple-Forum or the respective product's forum (i.e. if the receiving side was a Zyxel modem, ask there)

One perhabs helpful article...

IKEv2 profile broken since Sonoma 14 - Apple Community

discussions.apple.com

 

[cwagz78]

What does the server side look like?

Any logs?

*Better post on the Apple-Forum or the respective product's forum (i.e. if the receiving side was a Zyxel modem, ask there)

One perhabs helpful article...

IKEv2 profile broken since Sonoma 14 - Apple Community

discussions.apple.com

Thank you for the reply. I am running pfSense and have had zero issues up until 14.2.

I don't have the logs right now. It really seemed like it was just not saving the pre-shared key correctly. Thank you for the link to the apple discussion board. That looks like some promising information.

I have setup Tailscale and I am considering abandoning my IPsec VPN. So far it is working well and does not require a profile to be configured correctly. It can even do connect on demand with rules from the app now on the iphone.

 

[mygu]

I have found a fix (or workaround?) for this issue: if you set the lifetime of the phase 2 / SA / proposal on the VPN server side to a value less than 1440 seconds / 24 minutes (1200 seconds / 20 minutes for example), then the connection will rekey before the 24 minute mark, and it'll rekey correctly without dropping.

It seems that when the iOS/macOS devices hits the default lifetime limit of 24 minutes, it tries to rekey but maybe uses incorrect values, so the VPN tunnel drops since it couldn't rekey. But when the server-side lifetime expires, the rekey is successful (maybe since the server initiates the rekey using the correct values?), and the connection stays up and works perfectly fine, so the trick seems to be to make sure the server lifetime always expires before the Apple device client lifetime, so just set something shorter than 24 minutes on the server side (20 minutes, for example) and you should avoid the problem.

I use a MikroTik router running RouterOS 7.12 as my IKEv2 VPN server. Setting lifetime=20m (or something else less than 24m) under the VPN proposal fixed it for me. I last used the VPN for over an hour without any issues. I haven't used Apple Configurator to modify settings on my iOS/macOS devices (running iOS 17.1.1 and macOS 14.1.1 Sonoma), so the VPN settings on the clients are the defaults that Apple sets. My other settings include using SHA256, aes-256-cbc, and ecp256 as the PFS group.

I hope this helps.

It's a perfect workround. Just simply change on my MikroTik router in minute.

 

[miken32]

Have been bothered by this for months but just figured it out. Basically, macOS is ignoring what's specified in the configuration profile and you'll have to do some debug-level logging on the VPN server to figure out what settings it's actually using. In my case, despite the profile saying to use DH20 to build the child SA, macOS starting with Sonoma will in fact use DH19, so I had to make sure my VPN server supports DH19 (aka ecp256) PFS as well as DH20 (ecp384.) PFS doesn't get set up until the first rekeying, which is why there are no errors on the initial connection and why it was cutting out for me after ~20 minutes. iOS (and previous macOS versions) use DH20 as specified in the configuration profile.

For the record, to help anyone in the future, this is the relevant part of my configuration profile:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>PayloadContent</key>
    <array>
        <dict>
            <key>IKEv2</key>
            <dict>
                <key>IKESecurityAssociationParameters</key>
                <dict>
                    <key>DiffieHellmanGroup</key>
                    <integer>20</integer>
                    <key>EncryptionAlgorithm</key>
                    <string>AES-256-GCM</string>
                    <key>IntegrityAlgorithm</key>
                    <string>SHA2-384</string>
                    <key>LifeTimeInMinutes</key>
                    <integer>120</integer>
                </dict>
                <key>ChildSecurityAssociationParameters</key>
                <dict>
                    <key>DiffieHellmanGroup</key>
                    <integer>20</integer>
                    <key>EncryptionAlgorithm</key>
                    <string>AES-256-GCM</string>
                    <key>IntegrityAlgorithm</key>
                    <string>SHA2-384</string>
                    <key>LifeTimeInMinutes</key>
                    <integer>15</integer>
                </dict>
            </dict>
        <dict>
    </array>
</dict>
</plist>

And despite these very specific settings, it was using this to connect:
IKE SA:

IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/MODP_2048
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/ECP_256
IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048

Initial child SA:

ESP:AES_GCM_16_256/NO_EXT_SEQ
ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ

Rekey child SA:

ESP:AES_GCM_16_256/ECP_256/NO_EXT_SEQ

 

[re-cycle]

Huge thanks to everyone above who diagnosed this - literally saved me hours.

For anyone using an Azure Point to Site VPN, this can be solved server-side by switching the P2S IPSec/IKE policy configuration from Default to Custom.
Then in IKE Phase 1
Change Integrity/PRF to SHA256
Change DHGroup to ECP256

In IKE Phase 2(ipsec)
Change PFS Group to ECP256

Change IPSec SA lifetime in seconds to 1200 (ie 20 mins so it renegotiates before the 24 mins Apple client re-key). (Ignore the error about lower SA lifetime values resulting in performance issues)

FYI: I'm using this with an Azure Certificate for authentication type. Not sure if this would work with shared secret but I see no reason why not.

Also, for windows clients to then use the VPN you need to edit the %appdata%\Microsoft\Network\Connections\Pbk\rasphone.pbk file to replace NumCustomPolicy=0 with
NumCustomPolicy=1
CustomIPSecPolicies=020000000400000004000000050000000200000004000000
which tells the windows client to use the improved security cyphers listed above.

 

[GuruBob]

Same issue here, Sonoma 14.6.1 (23G93). Drops at the 24 minute mark exactly. Does not happen for a connection on an iPhone. Our tech provider is unable to change the rekey time on the VPN so best I can hope for is that Apple fix this bug.

 

[GuruBob]

Update to Sequoia did not fix this issue.

 

[Mcrumors David]

Update to Sequoia did not fix this issue.

Noone was holding their breath, the golden rule has become: Do not update to the yearly, rushed major version until x.1

 

[Chip Chanko]

Is this actually a bug or just that Apple implemented their security in a way that most VPN providers haven't updated to yet?

 

[re-cycle]

Is this actually a bug or just that Apple implemented their security in a way that most VPN providers haven't updated to yet?

Not initiating rekeys would seem to decrease security to me.
Also, not supporting common VPN servers doesn't help with security.

On the other hand, Apple likely does not see this as a bug even though most real-world users experience it as such.

 

[Phathak]

Update to Sequoia did not fix this issue.

Sequoia 15.0.1 has been out for 4 days now. Have you tried upgrading to see if it fixes the issue?

 

[Phathak]

So yesterday I upgraded form 14.6.1 to 14.7. Didn't fix the problem, so I then wiped my drive and reinstalled from a bootable drive using 14.4. Then restored from a backup but omitted to restore the network settings. After the restore, my mac is effectively running 14.7 (?!) and my vpn did not drop the connection for the last 2 hours...

 

[Mcrumors David]

So yesterday I upgraded form 14.6.1 to 14.7. Didn't fix the problem, so I then wiped my drive and reinstalled from a bootable drive using 14.4. Then restored from a backup but omitted to restore the network settings. After the restore, my mac is effectively running 14.7 (?!) and my vpn did not drop the connection for the last 2 hours...

Yes. That is because the VPN profiles are transfered from an old (working setting / version) and hence keep functioning properly. If you create the VPN profile anew, it will not work.