Some of the approaches to this problem that I have thought about, but aren't perfect include: Enumerate the open TCP connections using sysctl() (similar to how netstat does it) and then force-close them using pfctlinput(PRC_UNREACH_PORT, &addr). This seems like it should work, but it doesn't do anything to address UDP flows that ought to be closed. Restarting the NETransparentProxyProvider seems like it should cause the kernel's flow director to restart, but I can't really find any documentation on how this works and whether it would trigger the existing flows to be closed. It would also be nice if the transparent proxy provider could restart itself in this case. There is an undocumented syscall: pid_shutdown_sockets() that we could use to force-close sockets for an entire process. But this seems mostly used for suspend/resume operations. And it's probably a bad idea to try and use undocumented APIs. There is an undocumented method fetchFlowStatesWithCompletionHandler() that I had hoped would return a list of flows that we could close, but this does not seem to return the flows where we returned NO from handleNewFlow().

We don't typically use Xcode for development of this app (our build environment uses CMake and Ninja for the most part), but adding --identifier org.mozilla.macos.FirefoxVPN to the codesign arguments to the daemon binary seems to have gotten the service to run successfully across the upgrade.

Yes, the code signing identifier of the daemon changed as a part of the upgrade. We split the application from a monolithic binary into separate GUI and daemon executables. The designated requirement of the monolithic GUI hasn't changed: Executable=/Applications/Mozilla VPN.app/Contents/MacOS/Mozilla VPN designated => identifier "org.mozilla.macos.FirefoxVPN" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "43AQ936H96" And the designated requirement of the daemon has a different identifier: Executable=/Applications/Mozilla VPN.app/Contents/Library/LaunchServices/org.mozilla.macos.FirefoxVPN.daemon designated => identifier "org.mozilla.macos.FirefoxVPN.daemon" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "43AQ936H96" Is there a way to tell launchd about the change? We have also tried using a postinstall script to unload the daemon using launchctl bootout system/org.mozilla.macos.FirefoxVPN.service to no avail. There does appear to be some way to get launchd to accept the upgrade. For example, the following steps get back to a working machine after the upgrade: Disable our app's Allow in the Background permission in the Login Items settings. Delete the app bundle off disk and empty the trash. Close and re-open the System Settings to the Login Items page and wait for our app's entry to disappear. Re-install the application again and it works as expected.