does you scutil command work when you invoke it from a global context? That is, a launchd daemon running as root? It actually does! Directly using scutil would indeed be less messy than hacking with netcat. It seems that this would be the best workaround currently. Meanwhile I created the feedback for an official support: FB16332789 Thanks for your time!

Your remarks about incoming demands made me try some tests. I made a system launchd daemon that would periodically send packets to an IP within the VPN network. ICMP pings didn't work, but TCP connections (using netcat) would in fact make the tunnel connect without any GUI login! There are some caveats though. It seems that the daemon program must be run as the first user of the Mac. The tunnel wouldn't try to start if the program is run as root or as a second user (admin or not). Do you have some insights about this or other ideas? Thanks

The rules connect on any interface match. Relevant code extract: let ruleInterface = NEOnDemandRuleConnect() ruleInterface.interfaceTypeMatch = .any manager.onDemandRules = [ ruleInterface ] manager.isOnDemandEnabled = true

Yes, and with firewall disabled

I just use the primary interface for diagnostic. My main problem is how to start my tunnel before any user login on the UI (assuming FileVault is disabled). The use case is to be able to remotely, securely, and reliably access the Mac through the tunnel. You could call this feature "always-on", "server mode", or "unattended mode". To test if this feature works, I try to connect with SSH on the VPN IP. I cannot connect, so for purpose of experimentation, I try to connect with SSH on the primary interface IP, where I find out with scutil --nc list that my tunnel is disconnected, and that I can start it with scutil --nc start and then connect with SSH on the VPN IP. Without logging in on the UI. So, I, as a developer, used the primary interface to find out that in theory the system might be able to automatically start the tunnel on boot before user login, but for the end use-case this primary interface may not be reachable. So now I wonder, why can't the tunnel start itself on boot? Am I using it wrong? Is it a missing feature, a technical limitation, or a restriction that exists on purpose? I am especially confused because in the posts I linked in my first message, it is said that "a Network System Extension on macOS is started when the system starts", and that "network extension [will] run before user session".

Yes I mean the primary interface, which happen to be Ethernet in this case

Hi, I forgot to mention that I tried with FileVault disabled. To further explain my testing process: I install the app in a VM, open it to activate the extension and add a VPN configuration. I then try to connect to the VM after reboot with SSH and Remote Management on the VPN IP address. I can connect before UI login using the Ethernet interface IP, and even force the VPN on with scutil --nc start, which make the VPN IP accessible, but it kind of defeat the point of the "always-on" functionality.

Hi, I hit the same issue. I need to know if the tunnel is being stopped because of a user action or because of a shutdown. The reason "userLogout" is better suited for system shutdown imho. It kinda makes sense really. Shut downs are user initiates after all. Technically yes, but the user intent is different. In one case the user explicitly wants the VPN off, the other case it is an indirect consequence of another action. Anyway I opened another ticket FB15711899 , because I can't see the status of the one opened by macnd.