Recently, we've started seeing NSURLSession requested by the NEPacketTunnelProvider itself failing on iOS 16.2. Specifically, we're seeing this error:
Error Domain=NSURLErrorDomain Code=-1009 "The Internet connection appears to be offline." UserInfo={_kCFStreamErrorCodeKey=50, NSUnderlyingError=0x10b944130 {Error Domain=kCFErrorDomainCFNetwork Code=-1009 "(null)" UserInfo={_NSURLErrorNWPathKey=unsatisfied (No network route), interface: utun29, scoped, _kCFStreamErrorCodeKey=50, _kCFStreamErrorDomainKey=1}}, _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <7D0450F9-2229-459E-9A6E-DFD5C0D7D325>.<1>, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <7D0450F9-2229-459E-9A6E-DFD5C0D7D325>.<1>"
), NSLocalizedDescription=The Internet connection appears to be offline., NSErrorFailingURLStringKey=https:/..., NSErrorFailingURLKey=https:/..., _kCFStreamErrorDomainKey=1}
When we analyzed this, we can see the NE's NSURLSession actually "loopback" thru the NE (e.g. we see the SYN and subsequent ClientHello packets come in right after issuing the NSURLSession for the destination IP), which appears to be a change in behavior since:
- We were not seeing this on previous iOS versions (e.g. iOS 15)
- This "loopback" is supposed to only occur when using
createXyzThroughTunnelToEndpoint
methods: https://developer.apple.com/forums/thread/94430?answerId=286978022#286978022 - We're even seeing DNS queries (e.g. from these NSURLSessions) loopback into the NE.
This wouldn't be a problem except that these NE's NSURLSessions are now failing on iOS 16. We see two different behaviors for these failed NSURLSessions:
- NE receives the SYN/ClientHello packets and sends them thru to the server, but the NSURLSession fails after a few secs with Code=-1009.
- NE doesn't receive any packets from its NSURLSession, which fails immediately with Code=-1009.
Could there be something we're doing that can cause the "loopback" of our NE's NSURLSessions?
If not, has anyone else reported a similar issue with iOS 16?