“includeAllNetworks”

I'm encountering issues with using includeAllNetworks where NECP is denying adapter usage, among other problems. Are you aware of any specific reasons why setting default routes wouldn't direct traffic through the tunnel? Additionally, it seems that with includeAllNetworks, enforcing routes may not function as expected. Any insights or guidance you could provide on these matters would be greatly appreciated.

Ok, there's definitely a strange behaviour. If I delete all of the vpn profiles in Network preferences, only then I can connect NEVPNProtocolIKEv2 profile with IncludeAllNetworks flag. As soon as I add any other vpn profile I am no longer able to connect my IKEv2 profile. Even if I manually add some IPSec profile via Network prefeneces 🤯. This makes IncludeAllNetworks flag impossible to use in my vpn app.

One thing to note is that createTCPConnectionThroughTunnel does not work when includeAllNetworks is enabled. A previous post noted this issue as well see here

If you do not include IncludeAllNetworks are you able to connect your tunnel? Yes, setting it to false works perfectly - you can connect to vpn without problems

Currently, AlwaysON VPN is only supported on supervised iOS devices. It is configuration profile based only, and is limited to the built-in IKEv2 provider. There is no app-based customization support. It sounds like you want to have your own app with your own custom SSL provider, but with the alwaysOn-VPN-like behavior (forcing all traffic onto tunnel to avoid traffic leakage). On iOS 14, check out the new key, includeAllNetworks, in the NEVPNProtocol.h file. If VPN is enabled and this includeAllNetworks is set, VPN will make sure all traffic must be tunneled. If tunnel is not up yet, all traffic will be dropped. If tunnel is enabled manually, this key will continuously keep the tunnel up. If tunnel is onDemand, then tunnel will be brought up by onDemand. https://developer.apple.com/documentation/networkextension/nevpnprotocol/3131931-includeallnetworks

First, thank you for opening the bug report. I see it internally and have copied myself on it. A few things to note here; You mentioned: A VPN application coded with NETunnelProvider, set 'includeAllNetworks' to be true (if it's false then cannot reproduce this issue); Install the VPN application on the iPhone and switch it on; Connect the iPhone to the Mac Book Pro with a USB cable; If you test with either includeAllNetworks to be false or plugging in the iPhone device before you start the tunnel does it workaround this issue? Matt Eaton DTS Engineering, CoreOS meaton3@apple.com

I would suggest a more accurate name - ‘includeMostNetworks’ instead of ‘includeAllNetworks’. For any change in documentation, API names, or API behavior I would open an Enhancement Request here. Regarding: After reading the updated documentation, it is not clear what the ‘includeAllNetworks’ actually does, as when it is disabled, the VPN also sends most network traffic over the tunnel. The way I have always thought of this property is that it allows your tunnel to define a sweeping set of destination addresses without having to manually define all of these routes in your packet tunnel configuration.

I understand the philosophy behind that, but the user (and developer) experience seems subpar: macOS and iPadOS (on a WiFi iPad): If you set includeAllNetworks you can ensure all the user's traffic goes through the VPN tunnel, with no loss of functionality. iOS: If you set includeAllNetworks, you can ensure all the user's traffic goes through the VPN tunnel, but MMS will not work. Your choice is either let MMS work, but don't guarantee the remaining traffic goes through the tunnel or kill user's MMS functionality. MMS is currently treated differently by iOS when there is a WiFi connection, as seen in the logs - it diverts MMS traffic to the cellular network. Given how cell companies require MMS to be delivered, it doesn't seem out-of-line that it would also be treated differently by iOS if a VPN is active. And even if this wasn't the default, adding a flag to allow MMS to go outside a VPN seems really, really helpful here. (We already have an optional excludeLocalNetworks flag that only matt

Yes. If set includeAllNetworks to be false there is no such issue. Or firstly connect with the console without VPN switched on, when it shows messages then switch on the VPN it's also normal.

And a related question - if at the extension I configured a split tunnel (only some routes at the includedRoutes) - how it works with includeAllNetworks which supposes to send all traffic to the tunnel?

It's not even restarting the tunnel I it was existed before, it's also for creating it for the first time. Even if I simulate a new user - just creating a profile with includeAllNetworks = true, and start the VPN for the first time, I have the above problem. Doing the same thing but with includeAllNetworks = false, and there's no problem at all. Removing the profile also works. It's just this flag which causes the problem - all the traffic at the extension gets blocked, even if it's the first time I'm trying to create the tunnel.

Hello Kevin, It looks like includeAllNetworks has to be set on the VPN configuration when it's defined. Is that correct? Yes. Is there any way to set this on-the-fly? In our particular VPN interaction the Gateway tells the VPN client whether it wants the client to use includeAllNetworks, so we can't just hard-code it. Since includeAllNetworks forces all traffic through the virtual interface, if you need to make a configuration network call that needs to go outside the tunnel then this needs to be done while the tunnel is not configured or active. default 13:42:57.476293-0700 VPNExtension [C10 Hostname#0a01000a:443 failed path (unsatisfied (Path was denied by NECP policy), interface: en0, ipv4)] event: null:null @4.222s Right, if possible, I would gather the network configuration information before the tunnel is started, otherwise using this flag will not work for this case. Matt Eaton DTS Engineering, CoreOS meaton3@apple.com

The relationship between includeAllNetworks and the routing properties (includedRoutes and excludedRoutes) is complex. Our expectation is that a full tunnel, one that that sets includeAllNetworks, would not also set the routing properties. That’s the case that we fully support. If you also set enforceRoutes then they system might do what you want, that is, honour the routing properties even though you’ve set includeAllNetworks. However, I discussed your situation with the folks who work on this stuff and they tell me that this isn’t an option that we officially support. It might work, it might not. Try this out and reply back here with the results. I’m curious. Also, if this configuration is important to you then I recommend that you file a bug report with details about your use case. Please post your bug number, just for the record. You should do this even if the setup currently works. In that case we’ll use your bug as an indicator that folks are relying on this. Share and Enjoy —

Interesting. Do you happen to have includeAllNetworks set on your NETunnelProviderProtocol that is forcing all v4 network traffic through the interface? Matt Eaton DTS Engineering, CoreOS meaton3@apple.com