includeAllNetworks

You essentially have a few options here. Go full tunnel VPN, to which you could claim all the routes on your system by hand, or go with the includeAllNetworks flag on NETunnelProviderProtocol. Or, you could go with Per-App VPN and claim traffic for specific apps. Having apps connect to a listener so that you can route their traffic through the VPN in not the way to go here.

I've submitted a feedback issue about this, with sample code. It's extremely easy to reproduce with a minimal VPN. Right now it's blocking release of anything using includeAllNetworks for us, because loss of DNS resolution is completely unacceptable. Hopefully there's some simple way to resolve the problem. FB13331886

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.

Interesting. The bottom line is that it sounds like traffic is escaping the tunnel some how with includeAllNetworks = true and is therefore being dropped. At this point I think it would be good to open a DTS incident - https://developer.apple.com/support/technical/ so I can take a closer look at what is happening. Matt Eaton DTS Engineering, CoreOS meaton3@apple.com

While I can dream of a flag to allow MMS through I recommend that you do more than just dream. do you know of a way to allow MMS to go outside the VPN while otherwise keeping similar functionality to includeAllNetworks No. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Is there any other place in the system where VPN configs can be found? For macOS, System Preferences - Network is the standard place. You can use % scutil also to take a look at the Network Configurations via % scutil --nc list. If you do not include IncludeAllNetworks are you able to connect your tunnel? Matt Eaton DTS Engineering, CoreOS meaton3@apple.com

Another update: it looks like if I use URLSession instead of createTCPConnectionThroughTunnel to create a TCP stream, the connection works just fine with .includeAllNetworks set to true, but the connection doesn't go through the tunnel. It would be rather ironic if users switched this setting on expecting a more secure connection, only to have the app be forced to use a part of the API that doesn't tunnel a portion of their networking...

Thanks for both of you for the answers! And regarding to 'includeAllNetworks' - it sounds similar to always-on, but I want to force the user to always use the VPN, or he won't have traffic, but without letting him the option to disable this behaviour (so he won't be able to uncheck the on-demand for example). Is it possible? This way it will behave just like always-on when the user is not allowed to stop automatic connections.

If you’re concerned about ‘leaking’ traffic then your best path forward is to set includeAllNetworks. You can find more on this in Routing your VPN network traffic. IMPORTANT It’s likely that you’ll want to exclude some traffic, otherwise you can break things like Xcode debugging! Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hi Matt, thanks so much for your reply. We pass nil as the TLS delegate parameter when calling startTunnelWithOptions, so I don't think that should be an issue. I'd just like to re-state the conditions of the failure mode: .includeAllNetworks set to true in the provider settings leads to connections created with createTCPConnectionThroughTunnel not connecting createTCPConnectionThroughTunnel works normally when .includeAllNetworks is set to false Normal network operations with URLSession.shared work normally in the network extension with .includeAllNetworks set to true Normal network operations on the rest of the system (i.e., outside of the network extension) work normally with .includeAllNetworks set to true You gave the following possibilities as worth investigating (let's set aside #1 and #2 for the moment for the reasons mentioned above): The connection purely timed out. A better path became available and the viability changed, which is a way of describing that the tun

The fact that MMS fails when you set includeAllNetworks doesn’t surprise me. You’ve specifically told the system that you want all network traffic, which is at odds with standard cellco practice of requiring that MMS be delivered over the cellco’s network. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Interesting. I suspect something is capturing the local traffic for a specified interface before it is sent to the default route. Also if the includeAllNetworks or excludeLocalNetworks flags are set this could impact the situation as well. To figure out more on what is happening I would recommend opening a TSI so I can take a closer look at your entire configuration. If you do open a TSI, please attach a sample project that reproduces the your scenario.Matt EatonDTS Engineering, CoreOSmeaton3 at apple.com

Yeah, this one is odd. I have seen issues where using includeAllNetworks causes issues for networking tasks, e.g., DNS resolution or authentication outside of the VPN server before the tunnel comes up. In this case if your connection to the remote address is truly inside the tunnel then that should not be causing issues here. You mentioned earlier that you were using a WireGaurd base tunnel. If you go back to a vanilla install of NEPacketTunnelProvider, does this work for you?

I tried with an app that lets us send ping, see the same issue there. Can try with a new sample app, but I expect it would behave the same. Yes, for this experiment it was in destinationIP mode. IncludeAllNetworks is off. For split tunnel mode, we don't set the default route (Which was the mode for this test). We do set the default route when testing with split tunnel off, where the expectation is all traffic goes through tunnel.

Any ideas how to debug this? Well, not having any other VPN network configurations installed on the system and receiving the error for, Failed to register Personal IncludeAllNetworks VPN Session NESMIKEv2VPNSession due to Enterprise VPN session NESMVPNSession, is odd. I would try this on a fresh VM. If you can still reproduce the issue, take a sysdiagnose and open a bug report. - https://developer.apple.com/bug-reporting/ Matt Eaton DTS Engineering, CoreOS meaton3@apple.com