includeAllNetworks

MFA stands for Multi-Factor Authentication. But that detail isn't critical here — the key point is simply that the tunnel is up and established successfully (startTunnel completes without error, setTunnelNetworkSettings is applied), routing is in place, but the server is not forwarding traffic. The sample code I shared reproduces this exact state — it's a loopback tunnel that never forwards packets. The core issue remains: with includeAllNetworks = true, push notifications are not delivered over Wi-Fi regardless of the excludeAPNS setting, while on cellular they work as expected when excludeAPNS = true.

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.

Thanks for confirming that. Browsers have a lot of complex logic. If you create a small test app that uses the DNS more directly — for example, by fetching a resource with URLSession — does that have the same problem? I expect it will, but I just want to be sure. Also, I want to check some things about how your packet tunnel provider is set up: It’s in destination IP mode, right? As opposed to source app mode? The latter being per-app VPN. Have you set includeAllNetworks? I suspect you haven’t, but I just want to be sure. If you haven’t set that, are you claiming the default route? That is, are you adding a NEIPv6Route.default() value to the includedRoutes property? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I've since gone and uploaded yet another sysdiagnose where we seemingly see the same thing happens, this time, on every reinstall from Xcode. In this case, once the newly installed packet tunnel starts, all networking on the device is broken, and seemingly this reliably reproduces. However, it doesn't happen by default, usually after a day of not restarting the device and developing does this start happening again. I've barely had time to look at the sysdiagnose, but from the cursory look there's plenty of No route to host errors, which would explain why the packet tunnel is not able to connect. Why is there no route to host? Who knows. At the time of installation, the VPN profile of the app I'm developing is set to be used on-demand, and it is set to include all routes (0.0.0.0/0 and ::0/0). We are not using enforceRoutes or includeAllNetworks due to bugs. It seems that there is a discrepancy between the two packet tunnel instances (the old one and new one), and one of them is desperately trying to

This is such a critical issue for anyone who may even consider this flag. The only thing we can do are kludges. We can't even detect if the user has auto-updates enabled or when the update is occurring. The best I can think of is to send a notification (which will probably get ignored or not seen), before the update goes live, that when received in the NSE checks if the kill switch is enabled (which is implemented with includeAllNetworks), and if so tell the user to disable the kill switch and update the app. Other options being to inform the user of this terrible bug in iOS when they enable the kill switch. Or if the user open the app when a new version is available but haven't auto-updated yet. It's a lot to ask to have a feature in your app that can completely mess up a users phone (they have no internet connectivity, and not only need to restart the phone, but delete the profile buried in the settings first, to ever be able to use their phone) Seems ridiculous to put all the production value into

Finally we could resolve the MDM profile - network broken issue with MDM profile having VPN payload by setting IncludeAllNetworks to 0. IncludeAllNetworks 0

I should also point out that this talk from the latest WWDC mentions includeAllNetworks, and it seems strange that the behaviour we're seeing is intended.

[quote='841929022, RBmint, /thread/786651?answerId=841929022#841929022, /profile/RBmint'] supposedly can filter packets and redirect them into different TUN interface without changing the route table. [/quote] Apple platform do have something like this — like I said, two of everything! (-: — namely NECP. For some very limited details on that, see A Peek Behind the NECP Curtain. However, as a third-party developer you have a very limited view into NECP, and it certainly won’t help with this. The go-to doc on this is Routing your VPN network traffic. It explains: How includeAllNetworks represents a giant switch, which effectively disables destination IP routing. This setting is implemented using NECP. How enforceRoutes lets you continue using destination IP routing but prevents apps from bypassing that. [quote='841929022, RBmint, /thread/786651?answerId=841929022#841929022, /profile/RBmint'] I'm also a little bit curious about other VPN's split tunneling function. Do they not exist/not work on macOS at

My go-to reference for this sort of stuff is Routing your VPN network traffic [1]. This outlines two options for preventing ‘escapes’: For a full tunnel, set includeAllNetworks and then set exceptions via the various excludeXYZ options. For a split tunnel, set enforceRoutes. There’s some subtlety with this, as explained in the Enforce the inclusions and exclusions for a packet tunnel provider section. That leaves this: [quote='836623022, Andreas_CF, /thread/781996?answerId=836623022#836623022, /profile/Andreas_CF'] be able to block any traffic while the tunnel is not yet connected [/quote] Honestly, I’m not sure what the best path forward is for that requirement. I’m gonna research that and get back to you. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] I know you’ve seen this but I’m replying as if you haven’t so that our conversation makes sense to other folks reading this thread.

[quote='783517021, maksmart, /thread/783517, /profile/maksmart'] i found excludeAPNs property … works only when includeAllNetworks property is also TRUE. [/quote] Correct. [quote='783517021, maksmart, /thread/783517, /profile/maksmart'] I wonder if there is a possible way to make APNs bypass tunnel in split tunnelling mode? [/quote] No. Well, you can work out what IP addresses are being used by APNs and exclude those networks, but that’s going to be brittle. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Just adding additional details: Devices (various OS versions, MDM providers): Device 1: iPad Pro (Model: MLMN2LL/A) iPadOS Version: 16.7.11 MDM Provider: Microsoft Intune Device 2: iPhone 15 (Model: MTLV3LL/A) iOS Version: 18.4.1 MDM Provider: Microsoft Intune Device 3: iPad Pro (Model: MLMP2LL/A) iPadOS Version: 14.4.2 MDM Provider: Citrix Endpoint Management NETunnelProviderProtocol Properties: type = plugin identifier = XXXX-XXXX-XXXX-XXXX serverAddress = [Netscaler Gateway IP] password = { domain = user accessGroup = com.apple.managed.vpn.shared } identityDataImported = NO proxySettings = { autoProxyDiscovery = NO autoProxyConfigurationEnabled = NO HTTPEnabled = NO HTTPSEnabled = NO FTPEnabled = NO SOCKSEnabled = NO RTSPEnabled = NO gopherEnabled = NO excludeSimpleHostnames = NO usePassiveFTP = YES } disconnectOnSleep = NO disconnectOnIdle = NO disconnectOnIdleTimeout = 0 disconnectOnWake = NO disconnectOnWakeTimeout = 0 includeAllNetworks = NO excludeLocalNetworks = YES excludeCellularServices =