includeAllNetworks

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

If we define either includeAllNetworks or enforceRoutes, then the excludedRoutes are ignored, and all traffic gets tunneled. This is the part that needs to further investigation. I would expect that if you set includeAllNetworks to NO, enforceRoutes to YES, and then you have set of excludedRoutes that they be excluded from the tunnel and would go through the primary interface. I would open a bug report on this and add this to your thread.

The definition of excludedRoutes: excludedRoutes The IPv4 network traffic that the system routes to the primary physical interface, not the TUN interface. Makes it clear that they should not be sent to the TUN interface. This is not what's happening. If we define neither includeAllNetworks nor enforceRoutes, then the excludedRoutes are properly excluded. If we define either includeAllNetworks or enforceRoutes, then the excludedRoutes are ignored, and all traffic gets tunneled. We tested every combination of the enforceRoutes, includeAllNetworks, excludeLocalNetworks, and overridePrimary options. We can provide logs showing the network settings provided to the Network Extension framework at start time, along with the protocol settings, as well as the traffic from the excluded network going to the VPN extension.

Interesting. Regarding: In both cases includeAllNetworks and excludeLocalNetworks are both NO. If you set excludeLocalNetworks and enforceRoutes to YES does this properly exclude the traffic in your excludedRoutes? If not, then I would open a bug report here just to see if this is something that needs to be further investigated.

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.

^^ correction in the includeAllNetworks's link We have not enabled includeAllNetworks, and also as per doc, it is disabled/false by default. I also tried setting it false explicitly but no luck.

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

While I can dream of a flag to allow MMS through I recommend that you do more than just dream. do you know of a way to allow MMS to go outside the VPN while otherwise keeping similar functionality to includeAllNetworks No. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I understand the philosophy behind that, but the user (and developer) experience seems subpar: macOS and iPadOS (on a WiFi iPad): If you set includeAllNetworks you can ensure all the user's traffic goes through the VPN tunnel, with no loss of functionality. iOS: If you set includeAllNetworks, you can ensure all the user's traffic goes through the VPN tunnel, but MMS will not work. Your choice is either let MMS work, but don't guarantee the remaining traffic goes through the tunnel or kill user's MMS functionality. MMS is currently treated differently by iOS when there is a WiFi connection, as seen in the logs - it diverts MMS traffic to the cellular network. Given how cell companies require MMS to be delivered, it doesn't seem out-of-line that it would also be treated differently by iOS if a VPN is active. And even if this wasn't the default, adding a flag to allow MMS to go outside a VPN seems really, really helpful here. (We already have an optional excludeLocalNetworks flag that only matt

The fact that MMS fails when you set includeAllNetworks doesn’t surprise me. You’ve specifically told the system that you want all network traffic, which is at odds with standard cellco practice of requiring that MMS be delivered over the cellco’s network. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com