Search results for

“includeAllNetworks”

157 results found

Post

Replies

Boosts

Views

Activity

Reply to Push notifications not delivered over Wi-Fi with includeAllNetworks = true regardless of excludeAPNS setting
MFA stands for Multi-Factor Authentication. But that detail isn't critical here — the key point is simply that the tunnel is up and established successfully (startTunnel completes without error, setTunnelNetworkSettings is applied), routing is in place, but the server is not forwarding traffic. The sample code I shared reproduces this exact state — it's a loopback tunnel that never forwards packets. The core issue remains: with includeAllNetworks = true, push notifications are not delivered over Wi-Fi regardless of the excludeAPNS setting, while on cellular they work as expected when excludeAPNS = true.
Mar ’26
Setting includeAllNetworks usually blocks GW connection in the extension, "kernel ALF, old data swfs_pid_entry"?
I'm seeing the connection to the VPN gateway failing in our Network Extension (not a System Extension) most of the time. Sometimes it succeeds. There's no difference in what the application or the extension are doing in the two cases. I can't see a pattern to when it fails, but In the console I see different messages. The only thing I've seen showing up consistently on failures but not successes is the message about the swfs_pid_entry. On failure: vpn_extension Gateway address 10.10.10.10, port 443 kernel ALF, old data swfs_pid_entry <private>, updaterules_msg <private>, updaterules_state <private> vpn_extension connect failed with error 65 (No route to host) kernel connect() - failed necp_set_socket_domain_attributes vpn_extension Connect returncode 65 On success: vpn_extension Gateway address 10.10.10.10, port 443 trustd User has disabled system data installation.
5
0
2.3k
Jul ’22
Reply to IOS 18.1 broke my VPN app
Why is that a worry? This property does not seem to have any noticable effect anyways. The tunnel can still connect to any address. I assume this is only for display purposes in the VPN settings. But who knows, the documentation does certainly not provide any insights. What worries me is that you guys at Apple implement breaking changes like that without the slightest hint but that's another story. But I figured it out in the meanwhile. For some reason, includeAllNetworks has to be set true starting from 18.1.0. This by the way another setting that is totally unclear in the documentation. Setting a default route usually means to redirect everything. So what is include all networks supposed to mean in that context?
Nov ’24
Reply to On-demand rules
VPN On Demand wasn’t designed as a mechanism to prevent ‘leaks’. For that we have Always-on VPN. At least, we do with the built-in IKEv2 VPN transports. We don’t support that for third-party VPNs (r. 33804980). [quote='778896021, roee84, /thread/778896, /profile/roee84'] I'm not using flags such as 'capture all network' [/quote] Is this in reference to the includeAllNetworks property? If so, then you should definitely explore that option. It is the closest to Always-on VPN that you can get with a third-party VPN. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Apr ’25
Reply to nesessionmanager sometimes not deallocating tunnel on VPN disconnect
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.
Oct ’23
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
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
741
Feb ’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
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 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 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 Push notifications not delivered over Wi-Fi with includeAllNetworks = true regardless of excludeAPNS setting
MFA stands for Multi-Factor Authentication. But that detail isn't critical here — the key point is simply that the tunnel is up and established successfully (startTunnel completes without error, setTunnelNetworkSettings is applied), routing is in place, but the server is not forwarding traffic. The sample code I shared reproduces this exact state — it's a loopback tunnel that never forwards packets. The core issue remains: with includeAllNetworks = true, push notifications are not delivered over Wi-Fi regardless of the excludeAPNS setting, while on cellular they work as expected when excludeAPNS = true.
Replies
Boosts
Views
Activity
Mar ’26
Setting includeAllNetworks usually blocks GW connection in the extension, "kernel ALF, old data swfs_pid_entry"?
I'm seeing the connection to the VPN gateway failing in our Network Extension (not a System Extension) most of the time. Sometimes it succeeds. There's no difference in what the application or the extension are doing in the two cases. I can't see a pattern to when it fails, but In the console I see different messages. The only thing I've seen showing up consistently on failures but not successes is the message about the swfs_pid_entry. On failure: vpn_extension Gateway address 10.10.10.10, port 443 kernel ALF, old data swfs_pid_entry <private>, updaterules_msg <private>, updaterules_state <private> vpn_extension connect failed with error 65 (No route to host) kernel connect() - failed necp_set_socket_domain_attributes vpn_extension Connect returncode 65 On success: vpn_extension Gateway address 10.10.10.10, port 443 trustd User has disabled system data installation.
Replies
5
Boosts
0
Views
2.3k
Activity
Jul ’22
Reply to IOS 18.1 broke my VPN app
Why is that a worry? This property does not seem to have any noticable effect anyways. The tunnel can still connect to any address. I assume this is only for display purposes in the VPN settings. But who knows, the documentation does certainly not provide any insights. What worries me is that you guys at Apple implement breaking changes like that without the slightest hint but that's another story. But I figured it out in the meanwhile. For some reason, includeAllNetworks has to be set true starting from 18.1.0. This by the way another setting that is totally unclear in the documentation. Setting a default route usually means to redirect everything. So what is include all networks supposed to mean in that context?
Replies
Boosts
Views
Activity
Nov ’24
Reply to On-demand rules
VPN On Demand wasn’t designed as a mechanism to prevent ‘leaks’. For that we have Always-on VPN. At least, we do with the built-in IKEv2 VPN transports. We don’t support that for third-party VPNs (r. 33804980). [quote='778896021, roee84, /thread/778896, /profile/roee84'] I'm not using flags such as 'capture all network' [/quote] Is this in reference to the includeAllNetworks property? If so, then you should definitely explore that option. It is the closest to Always-on VPN that you can get with a third-party VPN. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com
Replies
Boosts
Views
Activity
Apr ’25
Reply to nesessionmanager sometimes not deallocating tunnel on VPN disconnect
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.
Replies
Boosts
Views
Activity
Oct ’23
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
Replies
Boosts
Views
Activity
May ’25
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
Replies
7
Boosts
0
Views
741
Activity
Feb ’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
Replies
Boosts
Views
Activity
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.
Replies
Boosts
Views
Activity
Jun ’20
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
Replies
Boosts
Views
Activity
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
Replies
Boosts
Views
Activity
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
Replies
Boosts
Views
Activity
Jun ’23
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?
Replies
Boosts
Views
Activity
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:
Replies
Boosts
Views
Activity
Sep ’22
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:
Replies
Boosts
Views
Activity
Oct ’20