includeAllNetworks

We moved our macOS NKE-based VPN over to Network Extensions a while back. Although Network Extensions offered us less control over the system traffic it also let us have a single code base for the core functionality on iOS & macOS, as well as offering the possibilty of MDM.The talk on Network Extensions for Modern macOS offered us some of the control back. The includeAllNetworks and excludeLocalNetworks flags are great to see. But- Are they only on macOS, or are the Network Extension parts of that talk also applicable to iOS?- Will those Network Extension flags function if the user is running macOS Mojave? - iOS 12? Or are they only going to work on Cataline/iOS13 and later?Users do tend to upgrade their macOS & iOS versions, but corporate customers upgrade slowly, and they're our market.One abillity of NKEs that we lost with Network Extensions was the ability to do an 'Always On' VPN which made sure that all traffic from the system was tunneled. Because we could make the NKE load at boot tim

Unless we said otherwise, everything in that talk is for macOS 10.15 only. Specifically, the includeAllNetworks and excludeLocalNetworks options are currently only available on the Mac. Or are they only going to work on [10.15] and later?… corporate customers upgrade slowly, and they're our market.Understood, but backporting NE features to previous OS releases is not practical. This is especially true for these new NE providers, as they depend on a key feature (system extensions) that is new in 10.15.The talk referred to Driver Extensions as user-independent, and providing something available at the system level, but not Network Extensions. Is that the case?Prior to macOS 10.15, VPN providers were per-user for three reasons:Commonality with iOS.VPNs often require user credentials.They are based on app extensions because there was no alternative.With the advent of system extensions that last point is no longer the case, so there’s an architectural framework for system-wide VPN. However, 10.15 does not

It's great to see VPN security improved with the includeAllNetworks and excludeLocalNetworks properties added to NEVPNProtocol. Would be really great if these same features could be brought to iOS soon as well. My feedback report: FB6970648Cheers,Rob

I can’t speak to the behaviour of specific third-party clients, but I will say that it’s perfectly feasible for clients to force traffic to run over a specific interface.As to what you can do about this, my recommendation is that you look at the includeAllNetworks and excludeLocalNetworks properties we added to NEVPNProtocol in iOS 13 beta. Share and Enjoy — Quinn “The Eskimo!” Apple Developer Relations, Developer Technical Support, Core OS/Hardware let myEmail = eskimo + 1 + @apple.com

Hello !We did check with built in IPSEC profiles also. No any customizations whatever.Behaviour was similar, that Facebook Messenger was able to send out packets using IP address of underlying Wifi interface (and 4G). Even created .mobileconfig profile, which included ` OverridePrimary=1`.Still same behaviour on 12.3.1.Will try your suggestion with `includeAllNetworks` on iOS 13 beta. Btw. do you have deeper documentation on behaviour than onhttps://developer.apple.com/documentation/networkextension/nevpnprotocol/3143658-excludelocalnetworks?language=objcbest regards,taavi

I've tried the transparent proxy approach although I have the same issue as reported here https://forums.developer.apple.com/thread/121823 with the save failing with error 'Missing protocol or protocol has invalid type'. I've used a NETunnelProviderProtocol as you've instructed in the replies but the error stays the same, scarce docs don't help much.Below is the result of dumping the protocol object that caused the error to the logs: type = plugin identifier = 7AB53020-1331-47DD-B39A-B3A3B90762E7 serverAddress = localhost identityDataImported = NO disconnectOnSleep = NO disconnectOnIdle = NO disconnectOnIdleTimeout = 0 disconnectOnWake = NO disconnectOnWakeTimeout = 0 disconnectOnUserSwitch = NO disconnectOnLogout = NO includeAllNetworks = YES excludeLocalNetworks = NO authenticationMethod = 0 reassertTimeout = 0 providerBundleIdentifier = [redacted]

That may not apply to your issue, but make sure that you don't have includeAllNetworks set to true (which would sound logical in the first place but causes all sorts of weird failures) in the NETunnelProviderProtocol instance you pass to the NETransparentProxyManager while configuring the proxy in the main app.Doing so causes a networking loop back into the transparent proxy that gets NECP deny messages, which really do not explain the base issue at all. Reported as FB7468866.

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

Hi Matt,I able to fix the IPC issues. Now i could see it is saving the configuation correctly. But next my expectation was to get the callback on App proxy provider(i.e. AppProxyProvider) but not getting the callback. Looks like it is not able to get into the network system extension. Network preference, extension status showing as Connecting...) Any thought please? ( {n localizedDescription = MyExtension n enabled = YESn protocolConfiguration = {n serverAddress = <23-char-str>n disconnectOnSleep = NOn includeAllNetworks = NOn excludeLocalNetworks = NOn providerBundleIdentifier = com.sample.extensionn }n onDemandEnabled = NOn} )Extension info.plist:<?xml version=1.0 encoding=UTF-8?> <!DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd> <plist version=1.0> <dict> <key>CFBundleDevelopmentRegion</key> <string>$(DEVELOPMENT_LANGUAGE)</string> <key>CFBundleDisplayName</key> <string>FPNetwor

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