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?

@meaton @eskimo - Thank you very much for all the answers! Since I got those dylibs from a 3rd party, I'll ask them if they can rebuild them without the @loader_path reference.

Thanks! We have a task to replace the BSD socket, but it will take some time. For a temp solution, do you think that using something like Reachability at the extension would help me know when the interface is available?

Before I saw your reply I tried to use NWPathMonitor to get available Interfaces, and even though en0 and en7 were 'available', I still got the 'no network' error sometimes. I'll try your suggestion with nw_connection_t and I'll update. Thanks!

Thanks @meaton, but this is exactly what I've asked - I don't need to capture all DNS traffic, so I have a split tunnel for DNS, but it still not working well. I'm copying (and editing a bit) the relevant part from my original question: So as a workaround, on a split-tunnel I have a list of 'match domains', and 'search domains'. But now it seems that the default interface will answer those queries as well, and they won't reach the tunnel's DNS. To verify this, I connected with the VPN, and when I checked 'scutil --dns', I got the list of resolvers, where resolver #1, wasn't the utun (it was en7), and it handled all the 'match domains'/'search domains'. All DNS queries with those domains were answered by the system's DNS server, and not by the VPN DNS server. Any idea how to force those DNS queries to the tunnel's DNS for a split tunnel? It seems that the matchDomains is not working..

@meaton I also have questions regarding this thread: I want that my containing app would be able to talk to its system network extension, via IPC. This is what I've did: I've added temporary-exception.mach-lookup.global-name with the value '$(TeamIdentifierPrefix)com.a.b.c' to the containing app's entitlements I've added temporary-exception.mach-register.global-name with the same value, '$(TeamIdentifierPrefix)com.a.b.c', to the extension's entitlements I've added a code at the containing app, to call extensionMachServiceName(from:) with the same value, '$(TeamIdentifierPrefix)com.a.b.c' Are the above steps correct? Are they even needed? The containing app can download (when the user approves) an updated version of both the app and the extension. Then the containing app will replace the extension with the new version, and the containing app will re-launch. Is there any known problem with IPC communication after replacing the app and the extension?

Sounds related to the same issue I reported some years ago https://developer.apple.com/forums/thread/131827 (there were other threads too)

Great, thanks eskimo!

Should I disable AMFI? amfi_get_out_of_my_way

I have the same issue, on macOS 13.4. I've implemented a sysExt custom VPN, and when connecting to the VPN, I see two new utuns. When disconnecting, only one of them is cleaned-up. While this weird behavior seems to work fine, things change when reaching a big number of utuns (around 95 utuns): Customers reported about slow connectivity, or sometimes - no connectivity at all. It seems that from that point (95 utuns) there are troubles with the DNS responses (No answers for DNS queries). Restarting the Mac will solve this problem, as it cleans the utuns. As mentioned in this thread, the IPv6 routing table looks 'weird', but the IPv4 routing table looks good. I have exit(0) at the code, after calling the stopTunnel completionHandler - so I tried to remove the exit(0), and tried to keep it but adding a 0.5 sleep before calling it - but it changed nothing. Is there any way to force clean those 'dirty' utuns? Any idea if a big num of utuns, can really cause the above (DNS/networking) problems?

Update: I found the issue, which was related to my app, and not to the OS in any way.

@eskimo Thanks for the quick reply (as usual)! For some reason I didn't get a notification about it, so just saw it, but I've updated that this was a bug on my app.

@eskimo Sure, and actually, I'm still struggling with it. I'm connecting to the VPN from the containing app (startVPNTunnel). I assume this creates a utun. I'm also adding an observer for 'NEVPNStatusDidChange'. When I'm getting the status update for 'Connecting', I'm creating an IPC connection from the containing app to the system extension. For some reason, this creates a second utun. Disconnecting the VPN will clean only one of those utuns. So each connection/disconnection, results in an extra utun remaining on the system. If I'm changing the logic a bit, and register to the IPC only when I'm getting the 'Connected' update (and not 'Connecting'), there will be only one utun, as expected. But I do need the IPC conenction ASAP, so I'm searching for a way to do it while 'Connecting', without creating another utun.