IKEv2 profile broken since Sonoma 14

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]

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

What an lazy post. Wow😐 (I wish ppl had to take a test to check if their intelligence is higher than a carrot before posting here)

• What exact error / problem do you get?
• What have you tried? (There are many suggestions here)

A_H001 wrote:

Hi, I have same problem about VPN. Ventura work fine but when upgrade Sonoma can’t connect vpn.

any solution?

i am new here. Could you Pls advice how to create case to Apple.

What an lazy post. Wow😐 (I wish ppl had to take a test to check if their intelligence is higher than a carrot before posting here)

• What exact error / problem do you get?
• What have you tried? (There are many suggestions here)

Exact same issue, all our machines that upgraded to Sonoma can't connect through IKEv2 VPN. Used to work perfectly before.

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

I just submitted a report as well!

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.

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.

I would like to point out that the problem you were facing may be different from the problem we are talking about here. I presume that you are referring to a rekeying problem which causes the VPN to disconnect after certain amount of time. But I believe many of us are facing an issue that IKEv2 VPN simply won't connect from the beginning.

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.