IKEv2 profile broken since Sonoma 14

It seems to be the case only with the new ikev2 vpn profiles created after Sonoma upgrade. The old profiles installed before continue to work fine.

For new profiles, Sonoma will not consider the SecurityAssociationParameters and force to use:

  Opportunistic PFS = YES

  DH = (

    RandomECP256,

  )

  Lifetime = 1800

After 24 minutes:

Client side:

CREATE_CHILD_SA MID=15 Initiator Request

CREATE_CHILD_SA MID=15 Responder Response

Server side:

received proposals: ESP:AES_GCM_16_256/ECP_256/NO_EXT_SEQ, ESP:AES_GCM_16_256/NO_EXT_SEQ

For me the solution was changing the Phase2 PFS Group to 19 (ECP_256) on server and also for Windows clients profile.

May be solved! I have a stable connection for over an hour now.

With some help from libreswan, we found that if you restrict the VPN server to only allow one IKE proposal, and one esp/phase2alg proposal it avoids the Monterey bug of sending the incorrect proposals. The bug happens during rekey. Another troubleshooting idea was to set ikelifetime shorter than the 24/48 minute rekey interval macOS uses.

Note: other answers mentioned enabling Perfect Forward Secrecy, I found that it was not necessary.

On the vpn server I had to change my `/etc/ipsec.d/ikev2.conf` to:

  rekey=no
  pfs=no
  ike=AES_GCM_C_256-HMAC_SHA2_256-ECP_256
  phase2alg=AES_GCM_C_256

In our macos/ios vpn profiles I set these xml values:

        <key>EnablePFS</key>
        <integer>0</integer>

        <key>IKESecurityAssociationParameters</key>
        <dict>
           <key>DiffieHellmanGroup</key>
           <integer>19</integer>
           <key>EncryptionAlgorithm</key>
           <string>AES-256</string>
           <key>IntegrityAlgorithm</key>
           <string>SHA2-256</string>
           <key>LifeTimeInMinutes</key>
           <integer>1440</integer>
        </dict>

        <key>ChildSecurityAssociationParameters</key>
        <dict>
          <key>DiffieHellmanGroup</key>
          <integer>19</integer>
          <key>EncryptionAlgorithm</key>
          <string>AES-256</string>
          <key>IntegrityAlgorithm</key>
          <string>SHA2-256</string>
          <key>LifeTimeInMinutes</key>
          <integer>1440</integer>
        </dict>

I was able to resolve this by changing both the VPN Server ikev2.conf and VPN client profile. See discussion over at https://github.com/hwdsl2/setup-ipsec-vpn/issues/1486. Here's what I did:

1. Fully delete the old VPN profile on the macos/ios client. (System Settings > Profiles > Delete)

2. Change the VPN server settings and restart the VPN service.

ssh your_user@your_vpn_ip

# Edit ikev2.conf 
sudo vim /etc/ipsec.d/ikev2.conf

# Inside /etc/ipsec.d/ikev2.conf
  # Comment out old settings
  # pfs=no
  # ike=aes...
  # phase2alg=aes...
  pfs=yes
  ike=aes256-sha2_256;dh19
  phase2alg=aes256-sha2_256
# Inside /etc/ipsec.d/ikev2.conf

# Save and quit vim, :wq

# Restart the VPN service
sudo service ipsec restart

3. Change the vpn profile XML. These match the defaults in the Apple Dev docs for ike-params and childsec-params. Three keys: ChildSecurityAssociationParameters, EnablePFS, and IKESecurityAssociationParameters.

        <key>ChildSecurityAssociationParameters</key>
        <dict>
          <key>DiffieHellmanGroup</key>
          <integer>19</integer>
          <key>EncryptionAlgorithm</key>
          <string>AES-256</string>
          <key>IntegrityAlgorithm</key>
          <string>SHA2-256</string>
          <key>LifeTimeInMinutes</key>
          <integer>1440</integer>
        </dict>

        <key>EnablePFS</key>
        <integer>1</integer>

        <key>IKESecurityAssociationParameters</key>
        <dict>
          <key>DiffieHellmanGroup</key>
          <integer>19</integer>
          <key>EncryptionAlgorithm</key>
          <string>AES-256</string>
          <key>IntegrityAlgorithm</key>
          <string>SHA2-256</string>
          <key>LifeTimeInMinutes</key>
          <integer>1440</integer>
        </dict>

4. Install the new profile on macos/ios, and test a connection.

5. Watch logs on the server to see which encryption algorithms it negotiates.

sudo grep pluto /var/log/secure | grep proposal | tail -3

# Correct Output
 proposal 1:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-ECP_256 chosen from remote proposals 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=ECP_256[first-match]
 proposal 1:ESP=AES_CBC_256-HMAC_SHA2_256_128-DISABLED SPI=09f87ed7 chosen from remote proposals 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED[first-match]

We also found that sometimes macOS Sonoma arbitrarily caches/omits the IntegrityAlgo. I found this today after ikeLifeTime=24h expired.

Other possible ike values in ikev2.conf on the server below. Keep in mind I constrain the server to one proposal as a workaround to get valid rekeys with `proposal 1`.

  #  mobileconfig with AES-256, SHA2-256, dh14
       ike=AES_CBC_256-HMAC_SHA2_256_128-HMAC_SHA2_256-MODP2048
  #  mobileconfig with AES-256, SHA2-256, dh19
       ike=AES_GCM_C_256-HMAC_SHA2_256-ECP_256
       ike=AES_CBC_256-HMAC_SHA2_256_128-HMAC_SHA2_256-ECP_256
  #  mobileconfig with these sections entirely deleted
  #    IKESecurityAssociationParameters
  #    ChildSecurityAssociationParameters
  #    EnablePFS
         ike=AES_CBC_256-HMAC_SHA2_256_128-HMAC_SHA2_256-MODP2048

# These can be commented out
# esp=...
# phase2alg=...

I am responding to the original post. It seems this thread is discussing disparate issues.

I also have the original issue (limited proposal settings allowed by macOS 14). Also using openbsd iked, and see the same proposal list in the logs when testing.

As pointed out, the settings work elsewhere.

I noticed on the Apple developer website at

VPN.IKEv2.IKESecurityAssociationParameters | Apple Developer Documentation

it states:

----

DiffieHellmanGroup

The Diffie-Hellman group.

For AlwaysOn VPN in iOS 14.2 and later, the minimum allowed value is 14.

In watchOS and tvOS, the minimum allowed value is 14.

Default: 14

Possible Values: 1, 2, 5, 14, 15, 16, 17, 18, 19, 20, 21, 31, 32

EncryptionAlgorithm

The encryption algorithm.

In watchOS and tvOS, the default value is AES-256-GCM.

Default: AES-256

Possible Values: DES, 3DES, AES-128, AES-256, AES-128-GCM, AES-256-GCM, ChaCha20Poly1305

IntegrityAlgorithm

The integrity algorithm.

In watchOS and tvOS, the minimum allowed value is SHA-2.

Default: SHA2-256

Possible Values: SHA1-96, SHA1-160, SHA2-256, SHA2-384, SHA2-512

--------

Based on the comments/observations in this thread, it appears that macOS 14 is ONLY accepting the "default" options, and is rejecting all other options that are documented as being "supported."

I really have little insight, but it seems to me that this is a one line error in the code, where somebody confused a "default" setting with an "exclusive" setting.

It also seems like something that would be trivial to fix, but I don't know where to make this observation, and doubt anyone at Apple would listen.

So, I decided to share here.

thanks

Updating to macos 14.1.1 (released yesterday) fixed this for me

After adding ECP256 and AES-GCM-256 support, it resolved our Sonoma issues.

I had this issue with an Algo VPN. The fix for me was installing the Wireguard client through the app store and it now works perfectly.

I would like to offer more observations. I used Algo VPN project to set up my VPN. I found that if I turned on the Connect On Demand option in the profile, the VPN can connect successfully. However, if I manually switch off the Connect On Demand, and then manually start the VPN, it would fail to connect. A re-installation of the profile can solve the problem. But this means that I will need to re-install the profile every time that I need to temporarily switch off the VPN. Annoying, but at least this is something working for now.

I solved (Frankenstein-ed) it for DH14 and lower on Sonoma 14.1.1 (🥲)

I used "Apple Configurator" to create a profile (.mobileconfig file) that I can then inject in System Preferences.

I was even able to connect through a VPN-Gateway I setup for Windows devices like this with lower Security (AES-128, SHA1-90, DH2).

Here is the config:

*Yes this is not an optimal solution. Preferable I would just update my VPN Server to DH19 (ECB256) but I can't just update old Zyxel-Modems which Production Environments rely on just because Sonoma is bugged.

**Yes I did downgrade several Macs to Ventura, wasting entire weekends on this, thanks Apple.

***This tells me how well beta releases are tested, and how bugs are addressed (I sent in several Bug Reports, did I hear back even once? nope)

1st: Did you use the Apple Configurator?

...Try to set the to "Dead Peer Detection Rate" to "None" (not that it makes any sense, but homour us)

2nd: What if you try something crazy (like I did during my testing) and set the VPN-Server to AES-128, SHA1-90 and DH2 | then setup the profile in Apple Configurator like that and try to connect (worked for me over the 24m mark ..."sure less secure" but this is for testing a) and b) most Windows users connecting to my VPN-Server on the Zyxel Modems are using that exact setup... )

*I might add: I am using the VPN setup on old Zyxel Modems (USG 40, 60) with Firmware from mid 2018.

I encountered the same issue. Algo VPN fails to work. I tried to set up a new VPN server and it still fails to work. Therefore, this is a problem related to the macOS system instead of any specific VPN set-up. I have submitted a ticket via Feedback Assistant. No replies yet.

We are having the exact same issue, all our machines that upgraded to Sonoma can't connect through VPN (IKEv2) to reach our office server.

Some additions. Very same VPNs continue to work with macOS Ventura, iPads and iPhones even upgraded to iOS 17. It is Sonoma only problem.