Search results for

includeAllNetworks

150 results found

Post

Replies

Boosts

Views

Activity

Reply to split Tunnel + exclude APNs
[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
May ’25
Reply to includeAllNetwork Problems.
Kevin, Regarding: The main issue I see at this point is that when I define includeAllNetworks and it takes effect, I can no longer connect to the gateway, even by IP address. That's when we're trying to open the actual VPN connection to the Gateway. How are we supposed to open the socket that's going to carry the gateway traffic in this case? The VPN connection that you are trying to open, is it to the address/hostname reported in NETunnelProviderProtocol's serverAddress and out in initWithTunnelRemoteAddress for NEPacketTunnelNetworkSettings? If so, then I would open a bug report - https://developer.apple.com/bug-reporting/ about this and please respond back here with the Feedback ID. Matt Eaton DTS Engineering, CoreOS meaton3@apple.com
Apr ’21
Reply to Configure IKEv2 VPN with always-on
For AlwaysON VPN, to lock down the VPN, the iOS device is supervised and the AlwaysON VPN profile will be marked as non-removable by user. There is no UI option for user to turn off the VPN to allow traffic to pass. With VPN IncludeAllNetworks, you can put the device in supervised mode and also marked the profile as non-removable. But the VPN UI will allow the user to turn the VPN on/off, allowing users to bypass VPN. Sounds like you need an option to disallow user to be able to turn off VPN via UI. Please file a radar for the request.
Jun ’20
When updating a VPN app with `includeAllNetworks`, the newer instance of the packet tunnel is not started via on-demand rules
When installing a new version the app while a tunnel is connected, seemingly the old packet tunnel process gets stopped but the new one does not come back up. Reportedly, a path monitor is reporting that the device has no connectivity. Is this the expected behavior? When installing an update from TestFlight or the App store, the packet tunnel instance from the old tunnel is stopped, but, due to the profile being on-demand and incldueAllNetworks, the path monitoring believes the device has no connectivity - so the new app is never downloaded. Is this the expected behavior? During development, the old packet tunnel gets stopped, the new app is installed, but the new packet tunnel is never started. To start it, the user has to toggle the VPN twice from the Settings app. The tunnel could be started from the VPN app too, if we chose to not take the path monitor into account, but then the user still needs to attempt to start the tunnel twice - it only works on the second try. As far as we can tell, the first time a
7
0
637
Feb ’25
Reply to Change includeAllNetworks from NetworkExtension while tunnel is running
… 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
Jun ’23
Reply to On-demand rules
Thanks for the answer! For that we have Always-on VPN. IIRC, always-on is for managed iPhones/iPads only, and not for Macs, even when using a native VPN. Is this in reference to the includeAllNetworks property? If so, then you should definitely explore that option. Yes, that's what I was referring to. The basic scenario worked, but I have two issues with it: With this flag enabled, what would happen in the test I described: VPN is enabled, disconnect the WiFi and reboot the Mac, after the reboot, bring back the WiFi - would the traffic be blocked until the VPN starts, or is there some 'race', where some packets can be routed before the VPN starts? A bigger problem is there's no split-tunnel when this flag is enabled
Apr ’25
Reply to enforceRoutes causes excludedRoutes to be ignored
Ok, I'll open a report. When I say I checked every combination I do mean every combination, even ones that didn't make sense. I would have expected the behavior you described. This is the log from enforceRoutes YES, includeAllNetworks NO, excludedRoutes set (pruned a bit because it was pretty verbose): # Protocol properties seen by the extension: # [Jun 1, 2023 at 3:57:58 PM PDT] : Protocol Properties: . . . includeAllNetworks = NO excludeLocalNetworks = NO excludeCellularServices = YES excludeAPNs = YES enforceRoutes = YES . . . # Network settings we're passing to setTunnelNetworkSettings:completionHandler: # [Jun 1, 2023 at 3:57:59 PM PDT] : setting NEPacketTunnelNetworkSettings: { tunnelRemoteAddress = 10.200.1.200 DNSSettings = { protocol = cleartext server = ( 172.16.1.1, ) matchDomainsNoSearch = NO } proxySettings = { autoProxyDiscovery = NO autoProxyConfigurationEnabled = NO HTTPEnabled = NO HTTPSEnabled = NO FTPEnabled = NO SOCKSEnabled = NO RTSPEnabled = NO gopherEnabled = NO exclud
Jun ’23
Reply to With VPN switched on no messages can be seen on console and can not connect with Xcode
Thanks Matt. Just raised a bug report: FB8815876 (With VPN switched on no messages can be seen on console and can not connect with Xcode) Also add more details here for others to see if they can reproduce the same issue step by step. Description of the issue: When I tested with my iPhone SE(1st generation, iOS 14.0.1) on Mac OS Catalina 10.15.7 / Xcode 12.0.1 I found that with the VPN(NETunnelProvider, 'includeAllNetworks' set to be true) switched on there are no messages being shown on the console, and also on Xcode it shows 'iPhone(unavailable)'. After I switched off the VPN it came back to normal. I was using a USB cable to connect the iOS device with the MBP's left side USB port. Steps to reproduce: An iPhone SE(1st generation, iOS 14.0.1) / Mac OS Catalina 10.15.7 / Xcode 12.0.1; A VPN application coded with NETunnelProvider, set 'includeAllNetworks' to be true (if it's false then cannot reproduce this issue); Install the VPN application on the iPhone and switch it on; Connect the iPhon
Topic: App & System Services SubTopic: Core OS Tags:
Oct ’20
Reply to iOS VPN Issue -Disconnecting VPN from Packet Tunnel Network Extension Causes Loss of Internet Connectivity
I got this response from Apple: The behavior seen is expected with includeAllNetworks enabled. Once the VPN config is enabled, default drop is enabled, meaning traffic will be dropped unless they are tunneled. This is to prevent data leak across tunnel flaps. This sounds like exactly what is happening in your use case. If you leave the config enabled, and from your extension, you try to cancel the tunnel. This will leave the default drop enabled without tunnel, traffic will get dropped until tunnel comes back up. Query: But Now Which API to use to disconnect the VPN on NE side so that it doesn't causes any internet connectivity issue?
Jun ’24
Reply to Binding socket to an interface in Network Extension
One thing to note is that createTCPConnectionThroughTunnel(…) does not work when includeAllNetworks is enabled. Well, that’s annoying. IMO that’s eminently bugworthy. I don’t see a bug number on that other thread. Did you file a bug about this? If not, and this is causing you grief, I encourage you do so. And please post your bug number, just for the record. A previous post noted this issue as well see here You’re assuming I look at the threads that Matt is helping out on (-: I’m way too busy for that, alas )-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Topic: App & System Services SubTopic: Core OS Tags:
Sep ’22
Reply to Change includeAllNetworks from NetworkExtension while tunnel is running
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.
Jun ’23
Reply to Expected behavior of searchDomains
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
Feb ’26
Reply to NetworkExtension-based NKE replacement in Catalina
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]
Sep ’19
Reply to Traffic originated at the PacketTunnelProvider [lib-curl]
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
Feb ’21
Reply to How to configure PacketTunnelProvider settings
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.
Topic: App & System Services SubTopic: Core OS Tags:
Mar ’24