“includeAllNetworks”

regarding includeAllNetworks, if we reproduce this on e.g. iOS 14 or 15, what do you recommend, does it make sense to create a ticket for it, or those versions will not get fixed? DNS leak = DNS query requests that doesn't go through the tunnel. From what I've saw when setTunnelNetworkSettings(_:completionHandler:) is called, from the call point until almost its completion block is executed, the route to utun is deleted from system and then recreated. Because of this, requests made in this short time will not be able to go thru the tunnel and will most escape on e.g. en0. In the same time mDNS will fire lots of DNS queries at every network configuration change and some of the requests will manage to go around the tunnel, until the route is recreated.

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 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]

I'm using lib-curl from the provider. The traffic is not going via the tunnel. Is it possible to pass this traffic to the tunnel? I just want to confirm; are you including libcurl interfaces or a custom version of libcurl in your Packet Tunnel Provider, sending traffic via these APIs, and not seeing this traffic pass through the tunnel? If this is the case, you could look into using an In-Provider networking class like NWTCPConnection. - https://developer.apple.com/documentation/networkextension/nwtcpconnection If you are using libcurl for the HTTP stack you could also take a look at the CFMessage APIs, depending on how complicated your requests are. What should happen if I'll set the 'capture all traffic' flag? Will the traffic created from lib-curl at the provider will reach the tunnel? If you mean setting the flag for includeAllNetworks on NEVPNProtocol then, yes, all traffic should go through the provider in this instance. Matt Eaton DTS Engineering, CoreOS meaton3@apple.com

Transfer … packets safely, using full tunnel. To a VPN server that’s available on the public Internet? Note that there are two ways to achieve a full tunnel: Claim the default route. Do that are also set includeAllNetworks. The latter is tricky [1], and I recommend that you not attempt it until you’ve got more experience with this stuff. Actually, there's nothing special with DNS. From our perspective there’s a bunch of stuff special about DNS. If you’re building a VPN product, I recommend that you avoid trying to make assumptions about DNS because those are likely to break. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] For example, it can break the network interface required to talk to Xcode. See TN3158 Resolving Xcode 15 device connection issues.

Hi, Did you've managed to find a solution for this problem? I don't know if it helps, but we had the same issue when includeAllNetworks is used. We've saw that adding a delay at setTunnelNetworkSettings fixes the problem with sockets. We are using the C API, socket(). As far as I saw this is not working with NWConnection, but it works with createTCPConnection too. And for us was reproduced only starting with macos 13.X. The idea is something like: setTunnelNetworkSettings(networkSettings) { error in DispatchQueue.main.asyncAfter(deadline: .now() + 0.5) { <--- without this 0.5 delay is not working completeBlockFromStartTunelImpl(error) } } This is the link with our bug: https://developer.apple.com/forums/thread/723314 Another issue that we still have is that after reboot we cannot connect, even with the above delay. So the other fix is to delete the VPN profile from system. And in this case, until reboot everything works fine, until it breaks again :). Hope it helps.

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

[quote='790246022, mikeKane, /thread/756704?answerId=790246022#790246022, /profile/mikeKane'] Are you aware of any specific reasons why setting default routes wouldn't direct traffic through the tunnel? [/quote] Claiming the default route only affect traffic that relies on the default route. If the traffic has an explicit route, the system honours that. There are two common cases for this: If the traffic is to an address on a local network. If the connection is bound to a specific interface. [quote='790377022, mikeKane, /thread/756704?answerId=790377022#790377022, /profile/mikeKane'] Ideally, with includeAllNetworks, we would like to bind to each adapter and decide when each should be used. [/quote] I don’t understand this. When you say “we would like to bind”, is the “we” referring to your packet tunnel provider? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thank you for the timely response! I added an extra log call early in the constructor of our packet tunnel provider class, and saw no logs. We also tried a dummy implementation of a packet tunnel and also saw the same symptoms. We pontificated that it could be due to on-demand rules - if we disable those and try and update the app whilst our tunnel is connected we get the same results. That is not to say that we'd be happy to use a workaround that relies on not using on-demand rules. The issue number is FB16482585 and I've updated it with a sysdiagnosed that was collected with the appropriate VPN logging profile now. Not that we could do anything about the system not finding any route to the internet with includeAllNetworks set and the packet tunnel being shut down, but should a packet tunnel provider ever anticipate stopTunnel to be called with the appUpdate stop reason? Whilst on the topic of calls we've never seen in the wild, are there any circumstances we should be seeing a call to sleep? If the

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.

Going through the console, it actually seems that the profile is loaded properly: NESMVPNSession[Primary Tunnel:XRTC Accelerator:6CB1FD0B-6268-4701-8968-2EE37DE109AC:(null)] starting with configuration: { name = **** identifier = 6CB1FD0B-6268-4701-8968-2EE37DE109AC applicationName = *** application = com.***.*** grade = 1 VPN = { enabled = YES onDemandEnabled = NO disconnectOnDemandEnabled = NO onDemandUserOverrideDisabled = NO protocol = { type = plugin identifier = E8C022C7-41EE-4627-B2CD-88CE84D2A1DD serverAddress = VPN Server identityDataImported = NO disconnectOnSleep = NO disconnectOnIdle = NO disconnectOnIdleTimeout = 0 disconnectOnWake = NO disconnectOnWakeTimeout = 0 includeAllNetworks = YES excludeLocalNetworks = YES excludeCellularServices = YES excludeAPNs = YES enforceRoutes = NO pluginType = com*** authenticationMethod = 0 providerConfiguration = { key = value, } providerBundleIdentifier = ***.PacketTunnelProvider } tunnelType = packet } } but then I get [4768]: Tearing down XPC connec

If you are using a local DNS server that cannot be accessed due to all traffic going through the tunnel then this would explain why calls to getaddrinfo are failing. The logs in the console look like traffic is still trying to go over an interface that is not utun or ipsec related though. I'm wondering if you are getting this because of a routing change for the VPN's virtual interface and this traffic is not respecting that change. If you remove and includeAllNetworks and restart the VPN, does this resolve the errors in the log below? Not that this is a solution to your problem, I'm just trying to work through why this traffic is going around the tunnel interfaces if you instructed it not to. No mDNSKeepalive for interface en8/IOSkywalkLegacyEthernetInterface kr 0xE00002C0 NetWakeInterface: en8 <private> no WOMP uDNSCheckCurrentQuestion: host unreachable error for DNS server <private> for question failed to send packet on InterfaceID 0x5 en8/4 to <private>:53 skt 74 error -1 errno 6

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

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 =

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