macos Sonoma broke IKEv2, reconnects every 24-48 minutes #1486
Comments
0x-2a
changed the title
0x-2a
changed the title
0x-2a
changed the title
|
@0x-2a Thank you for reporting and providing details in this issue. Looking at the related discussion thread and provided logs, this is most likely a bug in macOS Sonoma, which might be sending incorrect parameters during IKEv2 rekey. Libreswan may have rejected the rekey request because it is incorrect. I am not sure if this issue can be worked around on the VPN server side. I would suggest that you instead report this bug to Apple and ask for a fix on their side. @letoams Please take a look to see if you have any suggestions on this issue. |
|
@0x-2a As a workaround, try:
Let us know if this workaround works for you. |
|
@hwdsl2 had some disconnects with that, but after playing with it a bit and reading some apple docs I was able to get a stable connection for 5+ hours now... edit ... still seem to get random disconnects when protocol 3 resolves instead of 1 On the server I set these values in And then locally on https://developer.apple.com/documentation/devicemanagement/vpn/ikev2/ikesecurityassociationparameters |
|
@0x-2a Thank you for the update. Just to confirm: You did not need to append |
|
Edit: server logs should show proposal 1 accepted, not 3 # On VPN Server
# Pull last 3 proposal lines
sudo grep pluto /var/log/secure | grep proposal | tail -3
# Correct Output
proposal 1:IKE=AES_GCM_C_256-HMAC_SHA2_256-ECP_256 SPI=747501102a70bac7 chosen from remote proposals 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_256;DH=ECP_256[first-match]
proposal 1:ESP=AES_GCM_C_256-DISABLED SPI=00da11ad chosen from remote proposals 1:ESP:ENCR=AES_GCM_C_256;ESN=DISABLED[first-match] |
|
Short: I downgraded to Monterey because of this (Ventura is to buggy) Long: |
|
@DunhamGitHub agreed. After letting some time go by, this is not the full fix because we're still seeing somewhat arbitrary disconnects, just less than the first every-24-minute issue. |
|
Edit later: removing the xml values works better @hwdsl2 @DunhamGitHub finally solved this with some help from @cagney over at libreswan libreswan/libreswan#1450 In my rekey=no
pfs=no
# Choose ike based on logs
# `sudo grep pluto /var/log/secure | grep pluto | grep proposal`
#
# Sonoma may send proposal without integrity algorithm, some variants I tested:
# XML with AES-256, SHA2-256, dh14
# ike=AES_CBC_256-HMAC_SHA2_256_128-HMAC_SHA2_256-MODP2048
# XML 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
#
# NOTE: this is technically wrong, intentionally mismatching to workaround the bug
# other clients (e.g. iOS) working properly will not be able to connect
ike=AES_GCM_C_256-HMAC_SHA2_256-ECP_256
esp=AES_GCM_C_256
#phase2alg is same as espIn our macos/ios vpn profiles remove these sections to allow defaults <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> |
|
On Wed, 6 Dec 2023, Joshua Hibschman wrote:
@hwdsl2 @DunhamGitHub finally solved this with some help from libreswan libreswan/libreswan#1450
In my /etc/ipsec.d/ikev2.conf I set:
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>ChildSecurityAssociationParameters</key>
<dict>
<key>DiffieHellmanGroup</key>
<integer>19</integer>
<key>EncryptionAlgorithm</key>
<string>AES-256</string>
That should be: AES-256-GCM
<key>IntegrityAlgorithm</key>
<string>SHA2-256</string>
This should be removed.
<key>LifeTimeInMinutes</key>
<integer>1440</integer>
</dict>
<key>IKESecurityAssociationParameters</key>
<dict>
<key>DiffieHellmanGroup</key>
<integer>19</integer>
<key>EncryptionAlgorithm</key>
<string>AES-256</string>
This should be AES-256-GCM
<key>IntegrityAlgorithm</key>
<string>SHA2-256</string>
This technically is wrong and should be removed, but apple seems to
reuse- integrity as the PRF. so leave it. Although on my servers I have
SHA2-512 here.
Paul
|
|
@letoams updated with words of caution |
|
@hwdsl2 @cpujoe yeah look for The whole block looks like this, which set "always-on VPN" for all Wifi connections, but not Cellular. Don't enable cellular, if you're in a low-coverage area your phone will work on reconnecting that VPN, causing problems with voice-over-lte (which for US carriers like Verizon is a vpn tunnel itself). <key>OnDemandEnabled</key>
<integer>1</integer>
<key>OnDemandRules</key>
<array>
<dict>
<key>InterfaceTypeMatch</key>
<string>WiFi</string>
<key>URLStringProbe</key>
<string>http://captive.apple.com/hotspot-detect.html</string>
<key>Action</key>
<string>Connect</string>
</dict>
<dict>
<key>InterfaceTypeMatch</key>
<string>Cellular</string>
<key>Action</key>
<string>Disconnect</string>
</dict>
<dict>
<key>Action</key>
<string>Ignore</string>
</dict>
</array>Or you can do it through the UI, on macOS it's buried under the
On iOS, similar route:
|
|
Here is an example of an "AlwaysOn" configuration that I found.
https://github.com/foot-gun/mobileconfig/blob/master/paranoid.mobileconfig
/Joe
…On Thu, Dec 7, 2023 at 9:22 AM Joshua Hibschman ***@***.***> wrote:
@hwdsl2 <https://github.com/hwdsl2> @cpujoe <https://github.com/cpujoe>
yeah look for <key>OnDemandEnabled</key> in the XML and set the key after
to <integer>1</integer>. Make sure the OnDemandRules after are what you
want.
The whole block looks like this, which set "always-on VPN" for all Wifi
connections, but not Cellular. Don't enable cellular, if you're in a
low-coverage area your phone will work on reconnecting that VPN, causing
problems with voice-over-lte (which for US carriers like Verizon is a vpn
tunnel itself).
<key>OnDemandEnabled</key>
<integer>1</integer>
<key>OnDemandRules</key>
<array>
<dict>
<key>InterfaceTypeMatch</key>
<string>WiFi</string>
<key>URLStringProbe</key>
<string>http://captive.apple.com/hotspot-detect.html</string>
<key>Action</key>
<string>Connect</string>
</dict>
<dict>
<key>InterfaceTypeMatch</key>
<string>Cellular</string>
<key>Action</key>
<string>Disconnect</string>
</dict>
<dict>
<key>Action</key>
<string>Ignore</string>
</dict>
</array>
Or you can do it through the UI, on macOS it's buried under the i.
Screenshot.2023-12-07.at.9.18.52.AM.png (view on web)
<https://github.com/hwdsl2/setup-ipsec-vpn/assets/1032983/305e9d9c-cb78-4587-8dc9-73493ec9d3f6>
On iOS, similar route:
- Settings > General > VPN & Device > VPN > hit the i next to your VPN
> Connect on Demand Toggle
—
Reply to this email directly, view it on GitHub
<#1486 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAIKPUER4QO7UIABEEGYPW3YIHGJ3AVCNFSM6AAAAAA7DGQ4WOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBVGQZDSNRWGA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
- Update VPN ciphers for compatibility with macOS 14 (Sonoma). Ref: #1486, libreswan/libreswan#1450
|
Here's a solution that works without VPN server changes (you might not have access to it) and any Mac OS configuration. |
Checklist
Describe the issue
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. VPN disconnects and reconnects once every 24-48 minutes (even with 14.1.1 update). Many issues reported for other VPNs running ikev, e.g. a quick search.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
No reconnects
Logs
Server (please complete the following information)
Client (please complete the following information)
Additional context
After some searching around the web, I found this, which mentions:
The text was updated successfully, but these errors were encountered: