@eskimo - Filed bug report FB13425443, so hopefully we can get some guidance on how to address this for our VPN implementation.

@eskimo - I and others with PacketTunnelProvider implementation would benefit from the feedback. Presumably they affect every other vendor. How can we get access to these suggestions, e.g. do we need to file our own bug or ?

This is a common problem affecting app using its own NE implementation (instead of using iOS's built-in VPN clients), e.g. commonly seen with VPN/PacketTunnelProviders. https://developer.apple.com/forums/thread/99042 Apple doesn't appear to be interested in fixing this, since they did nothing with the bug reported in that discussion thread. There must be some way to get Apple to do something about this. The battery impact is likely calculated based on the estimated cpu and radio usage for the traffic performed by the NE, so a simple thing for them would be to deduct the "inside" traffic being performed by apps going thru the NE from the "outside" traffic blamed on the NE when calculating battery usage.

I inadvertently included some private details in the message above, so I need to delete this and repost it w/o those details. Is that possible?

I inadvertently included some private details in the message above, so I need to delete this and repost it w/o those details. Is that possible?

I'm running into another case where it would be good to know if iCloud Private Relay is enabled: It breaks port 80 traffic for my PacketTunnelProvider. There are others also reporting this, e.g. https://developer.apple.com/forums/thread/687630 It would be better to have a fix specifically for that issue, but lacking that, I can at least implement a fallback if there was some way to programmatically detect if Private Relay was enabled.

Seeing this as well, and with iOS 15 GM. However, we discovered that "no route to host" error is only occurring with sockets, e.g. not with NWTCPConnection. Unfortunately, there are reasons we need to use sockets directly (e.g. setting socket options, binding to the network interface, etc), so this is not a viable solution. Can someone at Apple provide guidance on what we can do about this?

Hi Matt - Is there any other information needed to help figure out this issue, e.g. console output?

Hi Matt,We are using NETunnelProviderManager: let protocolConfiguration = NETunnelProviderProtocol() protocolConfiguration.serverAddress = "127.0.0.1" protocolConfiguration.providerBundleIdentifier = "com.xyz.mac.vpn.PacketTunnelProvider" manager.protocolConfiguration = protocolConfiguration manager.isEnabled = true manager.localizedDescription = profileName manager.saveToPreferences { (error: Error?) in if let error = error as NSError? { NSLog("Install error: \(error)") completionHandler?(error, false) } else { NSLog("VPN saved") self.loadManager { _ in completionHandler?(nil, true) } } }This creates the VPN in the Network system preferences and has a "Connect" button, which is what we're using to try to start our PT.The providerBundleIdentifier is the same one as in the log messages from nesessionmanager that I provided previously, and also is shown as being registered in the output I provided from pluginkit.