Looks like it was related to Microsoft Defender. Not sure exactly what was causing the problem, but removing MS Defender completely caused the issue to go away.

Thanks Jason. I'll pass this on to the customer. Our app has been on the store for years, and this is the first time we've ever heard about someone running into this, but they've got the screenshots to prove it. It sounds like it's something our customer should be raising an issue about.

Was there ever a solution to this found? I'm seeing this same error, both using BSD sockets and using NWConnection. (65 - no route to host for BSD sockets, 50 - network is down for NWConnection) The tunnel remote address, the server address in the config, and the address to which I'm connecting all match. I'm connecting via IP address, not by hostname.

After some more logging, I see that kernel connect() - failed necp_set_socket_domain_attributes Shows up even on success in some cases. Haven't seen kernel ALF, old data swfs_pid_entry <private>, updaterules_msg <private>, updaterules_state <private> on success

Turns out there was some profile on their system that was blocking it. They didn't want to go into more detail on that.

Thanks. I already added the logging profile, set the log config to debug, and turned up CFNETWORKS_DIAGNOSTICS. I'll take a look and see what I might have missed. I occasionally see the "failed necp_set_socket_domain_attributes" even in success cases, so I suspect that one's a red herring.

Still haven't figured out what to set to see the ALF data, but I noticed that there are some messages from netext about the connection that's failing. netext is a Microsoft Defender extension. If includeAllNetworks is on and Microsoft Defender is trying to do something with the traffic to the Gateway I suspect that it would be a problem. Are there any known issues that you can say anything about WRT anti-malware (e.g., Microsoft Defender) & proxy software (e.g., iBoss) interacting with VPN packet tunnels? It'll be tricky for me to find a test system which has none of these installed...

No, this was on a device running iOS 15. I haven't had any problems with iOS 16 so far.

Our problem isn't just orientation, and the failure message is consistent with every failure. The thing that seems oddest is that it will work fine the second call. In fact, if I break on the line of the call and make the same call in the debugger (and see it fail), then the call will succeed when I continue.

Encouraging hostname connections is fine, but sometimes literals are needed. Documentation to support that would be good.

Yes. Pre-iOS 16 we were just setting the IPv6 literal and it was working. With iOS 16.0.3 customers saw that IPv6 was not working at all. It looks like that may have been partly an Apple issue, because there was other commentary about this on the net with other applications, and some of the problems went away with 16.1. This caused a lot of confusion about just whose bug it was :-) With 16.1 we see that if we set an IPv6 literal without [] around it in the URL components host field then the resulting URL (components.url) has an empty host: https:///<rest of request path> When we set [] around the literal then we get a proper request: https://[<IPv6 literal]/<rest of request path> We do have it working at the moment on pre-iOS 16 & iOS 16.1+ by checking to see if the host in final URL is empty. We didn't want to do a check for OS version since we weren't sure exactly which one gave which behavior.

Also, when this is happening there is no high CPU... It looks like basically nothing is happening. When it locks up trying to quit it's the same thing. No churning CPU, just nothing happening.

Looks like this is connected with having a Swift class that implements a singleton using @objc class MyClass : NSObject { static let singleton = MyClass() @objc class func sharedInstance() -> MyClass { return singleton } When I access the class in the test case using: let myclass = MyClass.sharedInstance() I get freezes, and when I don't things work fine. There's no extra initialization being done in the initializer. Works fine running the unit tests through the CLI, but using the Xcode GUI breaks horribly. No messages about problems, no crashes, but Xcode is dead in the water at that point :-(

Cancel that. Still fails most of the time with the same symptoms & no information from Xcode... My singleton definition was straight from Apple's docs, but it was definitely the cause of the problem. I still have no $!!&%^$ idea what was going on, but changing it to static let singleton : MyClass = { let instance = MyClass() return instance }() Caused things to start working. Xcode was ridiculously opaque about what was failing, and why.

Ok, we figured out what was happening here. enforceRoutes doesn't just ensure that traffic destined for the tunnel gets there, it also makes sure that traffic which does not match the tunnel does not go to the tunnel. We set the DNS resolver as the IP of the VPN interface, but that's not always one of the includedRoutes for the VPN. In that case enforceRoutes ON will make DNS resolution not use the tunnel. The workaround appears to be adding the IP address of the VPN interface to the includedRoutes. We haven't seen any side-effects from that yet. This is a pretty weird behavior for enforceRoutes. Not the only unexpected problem we've seen with that flag -- We have another question open in the forums related to enforceRoutes as well, and its interaction with excludedRoutes: https://developer.apple.com/forums/thread/730456