There seems to be a bug in macOS 14 (14-14.1.2) that causes VPN connections to regularly disconnect after 24 or 48 minutes, causing a short network interrupt for 1-2 seconds. Prior macOS versions up to 13 do not have the issue. Release notes do not mention any breaking changes for 14, or 14.1.
The bug seems to be on the macOS side somewhere in the rekey/cert/proposal process. My vpn servers run libreswan 4.12 and are set to match the default security params from apple dev docs ikesecurityassociationparameters and childsecurityassociationparameters:.
How can I modify a VPN Profile (e.g. mobileconfig) to workaround the bug, or is there some new security param requirement in macos 14?
macOS logs
Console logs from macOS 14.1.2 process = NEIKEv2Provider show rekey failures. After each disconnect though, the connection successfully reconnects.
10:18 NEIKEv2Provider [CREATE_CHILD_SA R resp2 8A7ADF123EF55B23-DCF9CDCBGFBDE2A1] Rekey child received notify error Error Domain=NEIKEv2ProtocolErrorDomain Code=14 "NoProposalChosen" UserInfo={NSDebugDescription=NoProposalChosen}
10:18 NEIKEv2Provider Failed to process Create Child SA packet
10:18 NEIKEv2Provider <NEIKEv2Provider: Primary Tunnel (ifIndex 15)>: : Failed to set interface availability for ipsec0
10:18 NEIKEv2Provider Bootstrapping; external subsystem UIKit_PKSubsystem refused setup
10:18 NEIKEv2Provider cannot open file at line 46986 of [554764a6e7]
10:18 NEIKEv2Provider os_unix.c:46986: (2) open(/private/var/db/DetachedSignatures) - No such file or directory
10:18 NEIKEv2Provider [IKE_SA_INIT R resp0 BBA5FCDAD5CCD32C-09141E6F23975F7C] Initiator init received notify error Error Domain=NEIKEv2ProtocolErrorDomain Code=17 "InvalidKEPayload" UserInfo={NSDebugDescription=InvalidKEPayload}
10:18 NEIKEv2Provider <NEIKEv2Provider: Primary Tunnel (ifIndex 15)>: : Failed to set interface availability for ipsec0
10:18 NEIKEv2Provider <NEIKEv2Provider: Primary Tunnel (ifIndex 15)>: : Failed to set interface availability for ipsec0
VPN Server Logs (running Libreswan latest v4.12)
In recreating the issue, I noticed a difference on first connection when the client sets OnDemandEnabled=0 vs OnDemandEnabled=1. To be clear though, disconnects happen either way, perhaps after the first connection is cached on the system.
With OnDemandEnabled=0, the server shows the macOS sent only 1 proposal.
Dec 6 9:53:22 pluto "ikev2-cp" #1: proposal 1:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from remote proposals 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048[first-match]
Dec 6 9:53:22 pluto "ikev2-cp" #2: proposal 1:ESP=AES_CBC_256-HMAC_SHA2_256_128-DISABLED SPI=04591279 chosen from remote proposals 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED[first-match]
However, with OnDemandEnabled=1 the server shows macOS sent 4 proposals.
Dec 6 9:54:27 pluto "ikev2-cp" #5: proposal 4:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from remote proposals 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_256;DH=ECP_256 2:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_256;DH=MODP2048 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=ECP_256 4:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048[first-match]
Dec 6 9:54:27 pluto "ikev2-cp" #6: proposal 4:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from remote proposals 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_256;DH=ECP_256 2:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_256;DH=MODP2048 3:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=ECP_256 4:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048[first-match]
Dec 6 9:54:27 pluto "ikev2-cp" #7: proposal 3:ESP=AES_CBC_256-HMAC_SHA2_256_128-DISABLED SPI=0490053d chosen from remote proposals 1:ESP:ENCR=AES_GCM_C_256;ESN=DISABLED 2:ESP:ENCR=AES_GCM_C_256;ESN=DISABLED 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED[first-match] 4:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED