includeAllNetworks

Problematic: 0.0.0.0/1 128.0.0.0/1 Why are you using this approach rather than setting includeAllNetworks? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Do not hard-code BSD interface names, like pdp_ip0. It will end badly. I have a bunch of backstory about this in the various posts linked to from Extra-ordinary Networking. socket still send data via utun, witch is a vpn interface That can happen if the VPN sets includeAllNetworks. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I've submitted a feedback issue about this, with sample code. It's extremely easy to reproduce with a minimal VPN. Right now it's blocking release of anything using includeAllNetworks for us, because loss of DNS resolution is completely unacceptable. Hopefully there's some simple way to resolve the problem. FB13331886

One odd thing is that it's only things that rely on DNS that appear to be breaking. If I try to ssh/ping/etc. to a system by IP address it works fine. It looks like there's a supportsDefaultDrop flag set on the config when includeAllNetworks is set, 2023-10-27 13:13:22.077480-0700 0x50591 Debug 0xb588c 320 0 nesessionmanager: [com.apple.networkextension:] applyIPDefaultDrop: session TestConfig But it's not clear why this would only have an effect when we disconnect from the extension instead of calling stopTunnel from the management app. Or why it would only affect name resolution.

Tried it for the same case on iOS, and I found that when includeAllNetworks is set in the profile, the VPN status will get disconnected status after connecting. How should we use includeAllNetworks correctly on iOS/macOS? Any help is appreciate.

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

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.

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.

… while others, specially latest versions, handle this fine. Can includeAllNetworks be changed while the tunnel is running Given that this is working on the latest system, that sounds like a bug that we fixed. And on the same note, regarding [setTunnelNetworkSettings(_:completionHandler:)], can this be called multiple times while the tunnel is running? That’s expected to work. what I've saw each call to [setTunnelNetworkSettings(_:completionHandler:)] after VPN connected results in at least DNS leaks, because the routing table is recreated. I don’t understand what you mean by “DNS leak”. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com