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.

Could someone please assist me with this?

Thanks 🙏 @eskimo With the help of the NWPathMonitor API, I am able to get all available interfaces and bind the VPN interface to NWConnection object with NWParameters's requiredInterface property, and everything is working as expected

Hello @eskimo  , I apologize for any confusion. At the beginning, I mentioned the use of PacketTunnelProvider, and you responded with a suggestion to use the createTCPConnectionThroughTunnel method, which works perfectly for PacketTunnelProvider. However, we also have the NETransparentProxyProvider in the same target, which is why @arkadit mentioned NEAppProxyTCPFlow in his question. we need to establish connections with some IPs from this range from NETransparentProxyProvider subclass as well. Unfortunately, the createTCPConnectionThroughTunnel method is specific to the PacketTunnelProvider class and cannot be used in the NETransparentProxyProvider class. As a solution for NETransparentProxyProvider, we are planning to explicitly bind our NWConnection to the VPN interface using the requiredInterface property. Thanks

Yes, we want a link-local address in addition to the address, that we have specified in the NETunnelNetworkSettings object