Thanks for the response, Matt. We may have to change support from Big Sur and above to avoid conflict with KEXT based VPNs.
Last two queries:
Is there a way to create custom VPN tunnel or utun interface, from an app, apart from using NetworkExtension or KEXT, in macOS?
Is there a way to find out tunnel address, match domains and include routes of other VPN tunnels or utun interfaces created by other applications (kext or NE or any other way)? This may help us do some tricks with include routes and avoid route overlap. netstat -rn seems to be one way to get some of this information. Is there any better way?
Thanks for your response Matt.
Regarding
Is it possible to have one NEPacketTunnelProvider based VPN and one kext based VPN tunnel running at the same time? We are planning on supporting from macOS Catalina.
and
Is there a way to create custom VPN tunnel or utun interface, from an app, apart from suing NetworkExtension or kext, in macOS? Could that cause a route overlap or conflict with our NetworkExtension tunnel when running simultaneously?
We have no plans of using kext for our VPN tunnel. These questions are in context of our VPN using NetworkExtension and some other simultaneous VPN using kext. Since we can not control other VPN providers, we are trying to assess whether their kext based VPNs could be a challenge for our NetworkExtension base VPN tunnel.
Can you please answer these two questions with in this context as well as below question?
Assuming answer to second question is, yes, what would be the behaviour if there is include route overlap between our NEPacketTunnelProvider based VPN tunnel and other kext based VPN tunnel?
Thanks. Here is the feedback reported: FB9108985
Accepting you first reply as answer since it provides a very good solution.
I would expect name and PID to work equally well here, that is, they both work or they both don’t. That fact that’s not the case is weird.
Yep. Thats how it appears right now. If I go to Terminal or Activity Monitor and fetch the process ID of the running sysex, then Xcode attaches fine with PID. But if I use the name of the sysex, it just keeps on waiting to attach.
Try this…
Tried your suggestion and lldb provides the bundle identifier of the sysex as the candidate process. Copied and used the same to attach in Xcode and it still keeps on waiting to attach. Verified in Terminal (ps -ax | grep ***) as well as in Activity Monitor and they both provide bundle identifier itself as process name. lldb is able to attach with that name but Xcode is not. PID works fine in both cases.
Oh, and btw, if you want to debug from the start of your sysex, add a call to pause at the beginning of main. That’ll pause waiting for you to attach with the debugger (attaching delivers a signal which breaks you out of pause).
Thanks for this awesome suggestion. With this, I am able to get pid of the process in Terminal and use it to attach debugger in Xcode before any code is executed.
Thanks Matt. Here is the feedback ID: FB9108197
Thanks for the update Matt.
However, I received this issue with Packet Tunnel. Whenever includeAllNetworks is enabled, if PacketTunnelProvider tries to apply a split tunnel rule, the rule fails to apply (but no error returned) and packet tunnel receives all the traffic as if its full tunnel and wildcard match domain.
Now I understand that when includeAllNetworks is enabled, split tunnel rules conflict with this setting and should not be used. But there is no clear documentation or error when settings split tunnel rules. There is just a cryptic message in Console.app System Policy: deny(1) system-privilege 10006 which is easy to miss. It does not even specify the problem.
So, I think it would be nicer to have documentation mention this conflict and its impact. It would be even nicer to have NETunnelProvider.setTunnelNetworkSettings method return an error in its completion block when such conflicts take place.
I was also facing this issue (deny(1) system-privilege 10006) with PacketTunnel on macOS and includeAllNetworks was the culprit. Thanks to your answer, I was able to resolve the issue (only after wasting more than a day). Has there been any update on FB7468866 to fix this issue?
Thanks @eskimo. That clarifies it.
