includeAllNetworks

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

@matt, thanks for the support :) The configuration for packet tunnel is that: protocolConfiguration type = plugin identifier = 7FCF645B-4707-42AE-BFB9-76903115D4F5 serverAddress = x.x.x.x:PORT // This is IP:PORT FORMAT identityDataImported = NO disconnectOnSleep = NO disconnectOnIdle = NO disconnectOnIdleTimeout = 0 disconnectOnWake = NO disconnectOnWakeTimeout = 0 includeAllNetworks = NO excludeLocalNetworks = YES enforceRoutes = NO pluginType = bundleIdentifier of the app that contains the extension authenticationMethod = 0 reassertTimeout = 0 And the code of the start tunnel override func startTunnel(options: [String : NSObject]?, completionHandler: @escaping (Error?) -> Void) { let newTunnel = ClientTunnel() newTunnel.delegate = self if let error = newTunnel.startTunnel(self) { completionHandler(error as NSError) } else { // Save the completion handler for when the tunnel is fully established. pendingStartCompletion = completionHandler tunnel = newTunnel } } And the VPNStatus is .connected My

I suspect you want to gather some information to provide to your VPN in aide in tunnel connection, and that is why you want to make a network call before the tunnel is connected. You understood it correctly. Let me explain it again in more detail. As part of establishing VPN connection, Just after successful SSL Handshake with Tunnel Server, Tunnel Server provides one URL, Packet Tunnel extension passes this URL to VPN Controller App, and using this URL Controller App fetches some settings(user auth required). Since Network connectivity is blocked until the VPN is connected, we are unable to make a call to URL provided by Tunnel Server, and we have to make this call to fetch some settings which is required in order to establish VPN connection(before we return completionHandler(nil)). are you able fetch those resources inside the provider? As I mentioned above, unfortunately No. ` Since Network connectivity is blocked until the VPN is connected, unable to fetch required resources inside the provider. so presum

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