NEPacketTunnelProvider Start Issue on macOS 14.5

Question

Created Jun ’24

Replies 6

Boosts 0

Participants 3

We're encountering an issue with our Network Extension (utilizing NEPacketTunnelProvider and NETransparentProxy) on macOS 14.5 (23F79). On some systems, the VPN fails to automatically start after a reboot despite calling startVPNTunnel(). There are no error messages.

Our code attempts to start the tunnel:

.......
do {
  try manager.connection.startVPNTunnel()
  Logger.default("Started tunnel successfully")
} catch {
  Logger.error("Failed to launch tunnel")
}
......

System log analysis reveals the tunnel stopping due to userLogout (NEProviderStopReason(rawValue: 12)) during reboot. However, the Transparent Proxy stops due to userInitiated (NEProviderStopReason(rawValue: 1)) for the same reboot.

We need to understand:

Why the VPNTunnel isn't starting automatically. Why the userLogout reason is triggered during reboot.

Additional Context: We have manually started the VPN from System Settings before reboot.

Answered by DTS Engineer in 861370022

Is there any way that startVPNTunnel() can fail, without an error being thrown?

Well, I think you’ve answered your own question there (-:

Obviously this shouldn’t happen. A successful call to startVPNTunnel(…) isn’t guaranteed to bring up the tunnel, but it should at least get it into the .connecting state. If that’s not happening, I think it’d be reasonable to file a bug about it.

Please post your bug number, just for the record.

Your bug will need a sysdiagnose log taken after seeing the problem. Ideally this sysdiagnose log would be:

Taken on a device with the VPN (Network Extension) debug profile installed; see our Bug Reporting > Profiles and Logs page for more on that.
Taken immediately after seeing the problem.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Boost

Answer 1

Appleaholic OP

Jun ’24

Could someone please assist me with this?

0

Answer 2

DTS Engineer OP

Apple

Jul ’24

So am I to understand that this didn’t happen on earlier releases of macOS 14.x?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 3

Appleaholic OP

Jul ’24

Thank you for your response on this thread.

Yes, we have observed this issue only on macOS 14.5 (23F79) systems.

I have been investigating the issue and found the following:

The NEProviderStopReason code 12 UserLogout occurs on systems that are domain-joined. On reboot, the VPN tunnel stops with status code 12.
On non-domain-joined systems, on reboot, the VPN tunnel stops with status code 1 UserInitiated.

This behavior/NEProviderStopReason code is not the problem. The actual issue is why the VPN tunnel is not starting after reboot when we call the "startVPNTunnel() API". Additionally, it is concerning that this API does not throw any error if it is failing.

0

Answer 4

DTS Engineer OP

Apple

Jul ’24

Thanks for the additional info.

We’re currently seeding both a macOS 14.6 beta and a macOS 15 beta. Have you tested this on either of those?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0

Answer 5

dylandylandylan OP

3d

Hi, we've been seeing occurrences of this issue from time to time in Sonoma, Sequoia, and Tahoe.

From our observations, it seems that the issue is rare, but certain devices can reproduce it relatively consistently on boot. A pattern hasn't been established between these devices yet.

As posted by @Appleaholic above, when we try to call NEVPNConnection's startVPNTunnel() from within a do-catch statement, no error is thrown. However, the VPN never enters a Connecting/Connected state.

Is there any way that startVPNTunnel() can fail, without an error being thrown?

0

Answer 6

DTS Engineer OP

Apple

2d

Recommended

Is there any way that startVPNTunnel() can fail, without an error being thrown?

Well, I think you’ve answered your own question there (-:

Obviously this shouldn’t happen. A successful call to startVPNTunnel(…) isn’t guaranteed to bring up the tunnel, but it should at least get it into the .connecting state. If that’s not happening, I think it’d be reasonable to file a bug about it.

Please post your bug number, just for the record.

Your bug will need a sysdiagnose log taken after seeing the problem. Ideally this sysdiagnose log would be:

Taken on a device with the VPN (Network Extension) debug profile installed; see our Bug Reporting > Profiles and Logs page for more on that.
Taken immediately after seeing the problem.

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

0