Post not yet marked as solved
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..
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!
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?
Post not yet marked as solved
@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.
Post not yet marked as solved
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?
Post not yet marked as solved
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)?
Post not yet marked as solved
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?
Post not yet marked as solved
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?
Post not yet marked as solved
@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?
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')?
@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.
Post not yet marked as solved
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)?
Post not yet marked as solved
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?
Post not yet marked as solved
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)
Post not yet marked as solved
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.
