I've implemented a custom system extension VPN for macOS, using a Packet Tunnel Provider. I saw something suspicious on macOS 15.2.0: When I disconnected my VPN, the UTUN was not being cleared. This results in a lot of UTUNs when the user connects and disconnects multiple times. utun77: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 utun78: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1500 This happens only on macOS 15.2. I tried the same app on older versions (15.0, 15.1.x), and it didn't reproduce. Can those 'dirty' UTUNs cause a networking problem? Since it happens only on macOS 15.2, is there a bug in this OS version? How can I check if something in my code causes this behavior? How can I 'fix' it or force clean the 'dirty' UTUNs?

Hello, My team has developed a DNS proxy for macOS. We have this set up with a system extension that interacts with the OS, and an always-running daemon that does all the heavy lifting. Communication between the two is DNS request and response packet traffic. With this architecture what are best practices for how the system extension communicates with a daemon? We tried making the daemon a socket server, but the system extension could not connect to it. We tried using XPC but it did not work and we could not understand the errors that were returned. So what is the best way to do this sort of thing?

NEFilterManager.shared().loadFromPreferences { loadError in DispatchQueue.global.async { ... } } the code above is executed in an app-like deamon and completionHandler was never invoked, same code in an application works fine.(they are both packed with content filter network system extension) is it because of the restriction of app-like deamon?

I've implemented a custom VPN for macOS (system extension, Packet Tunnel Provider, Developer ID). My tunneling logic uses BSD sockets. My VPN is configured with on-demand and should always connect when there's traffic: targetManager?.isOnDemandEnabled = true targetManager?.onDemandRules = [NEOnDemandRuleConnect()] I have encountered some issues when the device enters sleep (or waking up from sleep). I've tried two scenarios. Scenario 1: protocolConfiguration?.disconnectOnSleep = true With this flag set, the OS will disconnect the VPN just before entering to sleep. However, there were cases when the OS disconnected the VPN but immediately restarted it - probably because of how I defined the on-demand rules. This resulted in the VPN disconnection, then trying to reconnect, and then the Mac entered sleep. When the Mac woke up, the VPN didn't work well. Is there a way to avoid waking up, just before the Mac enters sleep? Scenario 2: protocolConfiguration?.disconnectOnSleep = false Disconnect on sleep is unset, and I've implemented the sleep/wake functions at the provider. With this configuration, the OS won't disconnect the VPN, so even in sleep, the extension should stay 'alive,' so it won't have the problem from (1). But in this case, I had other problems: On sleep, I'm disconnecting the tunnel. But sometimes, on wake(), all my network calls fail. Are the interfaces still down? How can I detect this case from the system extension? Is it possible that the OS would call sleep and then quickly call wake? Is it possible that after sleep, the OS would call the startTunnelWithOptions() function? Is it possible to restart the extension from a clean state right from the wake() function?