Update: I just read that login items installed via Service Management framework won't appear at the system preferences, so no problem on this area.

Thanks eskimo! Two more questions: Should I submit a bug report? I guess I have nothing to do with "The process generates code, like with a JIT, and has problems with that.", but if it's the first reason - "Something invalidate a page of existing code" - is this 'something' can be my application? Or again, it's a case where I can't do anything like the first option?

Is your app or MDM config falling into a case where the Extension is being uninstalled somehow? This is basically what I asked - I know that the user didn't terminate/uninstall the extension (nor the app). What I want to check is if it was uninstalled (mistakenly) by the MDM, so this is why I'm wondering about those 2 lines: sysextd: received request to remove MDM payload with UUID **** sysextd: removed MDM payload with UUID **** Any clue on how to debug if it was uninstalled by the MDM?

No, this is the only difference. If I'm setting newSettings.ipv4Settings?.includedRoutes =  [NEIPv4Route.default()] The traffic won't reach to the Ethernet proxies. Setting includedRoutes to some specific routes will behave differently - all routes (+ the routes included at the tunnel) will be sent to Ethernet proxies.

Thanks for the advice :) I did try to check the behavior, and when the user upgraded the app, he needed to allow system extensions again. This was unexpected (for me) so this is the reason I asked this. However, the user got the first version of the app via an MDM service, and then (few days later), the app inform the user that a new version is available, and the user chose to install it. Here the installation wasn't don't via MDM. So to summarize, I'm not sure if the 'please allow system extension' popup at the second time is expected/ a bug / or if it's related to who/what installed the new version.

The proxy is set at the system level via System Preferences. Why does traffic that claimed by the tunnel is getting sent to this proxy? (On a 'full tunnel', the traffic won't reach this proxy)

Does this traffic also match the proxy rules? Yes, the proxy should handle all traffic. However, it seems like an inconsistent behavior - on a full tunnel, traffic won't reach the proxy (and the traffic matches the proxy rules), and on split-tunnel, all traffic will reach the proxy, even the "claimed" traffic. Isn't it a bug? Anyway to bypass this without changing the proxy settings?

Thanks @meaton! Regarding so if your provider has not crashed or a new instance has not been created the previous state should be help in memory too If the user presses the 'connect' button, startTunnelWithOptions is called, then user disconnects, completion handler is called from the provider, and after a few minutes, the user reconnects again. I saw that it's still using the same provider, and not creating a new instance. Is this expected? Will it behave differently if the new connection will be started via on-demand rules (and not manually by the user)?

@dispatchMain - This behavior is documented: If the local system has System Extension developer mode enabled, the manager always calls this method when it finds an existing installation, even if the version identifiers match.

4 years later.. disconnectOnSleep is set: disconnectOnSleep = true And I have the following on-demand rule (to always connect when there's traffic): tunnelProviderManager.isOnDemandEnabled = true let onDemandRuleConnect = NEOnDemandRuleConnect() tunnelProviderManager.onDemandRules = [onDemandRuleConnect] This causes a problem on sleep - When the Mac is about to enter sleep stopTunnelWithReason is called (by OS) and VPN stops some other app has outgoing traffic the on-demand rule is matched, and the OS calls to startTunnel() //BUG here Mac enter sleeps, but the VPN is still 'enabled' There's no reason for the OS to restart the VPN if it's going to enter sleep mode. It should ignore on-demand rules in such cases. Any way to workaround this problem (and keep the 'disconnectOnSleep = true')?

@meaton Thanks for the reply! I tried what you said, but I'm still getting the 'Library not loaded: @loader_path/3rdParty.dylib' error. What I've tried so far: Drag the dylib files into the sysExt target (so they will be included at the 'Link Binary With Libraries' Add the dylib files into the 'Embed Frameworks' (build Settings) Then I tried to add the dylib files both to 'Link Binary With Libraries' and to 'Embed Frameworks' As I wrote before, I also set 'Dynamic Library Install Name', 'Dynamic Library Install Name Base', and 'Library Search Path' to the relevant lib folder. $(PROJECT_DIR)/libs But the extension still fails to find the dylib More details: I didn't create those dylibs, they are from a 3rd party I have also the headers, and I'm calling some of 'their' functions ('I'm using the API') - is it even possible to embed the dylib in such case? In case it relevant - I'm running the my app from Xcode, not from the Application folder (for development purpose) What else can I try here? Is there any way to 'debug' this / get more useful information?

Thanks for all the detailed answers! I checked at the relevant place ('YourApp.app/Contents/Library/SystemExtensions/mySysEtx/Contents/Frameworks/' and when I dragged the files to the extension, and also added them as embedded frameworks, the dylibs were at the correct location. However, when I run the extension it's still crashing with the same error: Termination Reason: Namespace DYLD, Code 1 Library missing Library not loaded: @loader_path/libwaresource.dylib Referenced from: /Library/SystemExtensions/*/com.myapp.mySysExtension Reason: tried: '/Library/SystemExtensions/C23234-someUID-1111111/com.myApp.mySysExtension.systemextension/Contents/MacOS/somelib.dylib' (no such file), '/usr/local/lib/somelib.dylib' (no such file), '/usr/lib/somelib.dylib' (no such file) (terminated at launch; ignore backtrace) If the dylibs are at the right place, why am I getting the 'Library not loaded' error?

I did find some workaround - I saw from crash logs that the extension is looking for the dylib at /Contents/MacOS/ and not at Contents/Frameworks (where the files are actually at) - I don't know what's causing it, but if I'm adding a 'Copy Files' build rule, and copying them as an 'Executables', it copies them to the /MacOS folder, so the extension can load them. Is it a good solution? How can I make the extension to try to search them at the framework folder? Once loaded, the dylib will search for a '.cfg' file in the same location. How can I copy 'cfg' file to the dylib location?

Thanks @meaton To conclude - all the dylibs are at the correct location (/Frameworks), the cfg is also at the correct location (/Resources), but I'm still getting the original error - Application Specific Information: Library not loaded: @loader_path/libwaresource.dylib Reason: tried: '/Library/SystemExtensions/A1111-someID-11111/com.myapp.myappSysExtension.systemextension/Contents/MacOS/libwavmodapi.dylib' (no such file), '/usr/local/lib/libwavmodapi.dylib' (no such file), '/usr/lib/libwavmodapi.dylib' (no such file) Why the extension is not looking the dylibs at the /Frameworks folder? Is it something I need to change at the Build Settings (search path for example)?

And last details: Running otool on one of the dylibs, shows this otool -L somelib.dylib somelib.dylib: @loader_path/somelib.dylib (compatibility version 4.0.0, current version 4.3.0) @loader_path/somelib.dylib (compatibility version 4.0.0, current version 4.3.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 904.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1292.60.1) Is it possible that the 'problem' is related to how the dylib was built? If the answer is yes, can I change some build settings at my extension to workaround this problem?