Lower level cpp APIs for creating TCP socket and reading/writing over it. This works perfectly always. Yes ms is milliseconds. I think no internet is seen at app level / http clients / apis. That's the reason URLSession also fails and Teams call also experiences drops. In this 2nd auth scenario, internet drop is only for few ms, on-demand connection succeeds eventually and we don't experience any issues.

We are still trying to test with NWConnection. But we use some other auth as well where URLSession isn't used but we still land into no internet for few ms (Teams call also experiences drops). So, I believe on-demand flow itself has some issues.

Why we are landing into no internet only during OnDemand connections? Is that a bug in Apple's ondDemand flow? Any known / documented bugs with URLSession?

Yes, from within Packet tunnel provider process. URLSession No state as such. Device loses internet connectivity

It stays in NO_INTERNET state until on-demand is disabled

let rule = NEOnDemandRuleConnect() rule.interfaceTypeMatch = .any manager.onDemandRules = [rule] manager.isOnDemandEnabled = true manager.isEnabled = true manager.saveToPreferences {} Yes, we need to contact VPN server and some other endpoints to get the configuration. But https requests are timing out because device is loosing internet connectivity (All apps + device)

Happening only when onDemand is enabled (Not at all when we manually call startTunnel and setup VPN tunnel settings).

Single User Machine has internet -> onDemand Enabled-> calls startTunnel() -> but before even we call setTunnelNetworkSettings(), internet goes away on machine So I am guessing some network settings are changing on machine in between leading to traffic going over incorrect interface.

App Extension

Apple team, Could you please check this?

Apple Support Team, could you please check this issue?

Problem is not with 0.0.0.0/0 Problematic: 0.0.0.0/1 128.0.0.0/1 Which covers entire IPv4 address range. When these routes are being added on TUN interface, forced tunneling is not working. Traffic is not going via tun interface but via Wifi interface. Route table is attached above. It correctly shows that routes were added on tun interface And this problem happens only on MACOS 14. Works correctly on MacOS 13

With 0/0, tun interface is prioritised Internet: Destination Gateway Flags Netif Expire default link#21 UCSg utun7 default 192.168.29.1 UGScIg en0

Route table shows routes are getting added on both tun and ethernet interface because of which traffic is not going via tunnel **0/1 192.168.29.1 UGScg en0 ** default 192.168.29.1 UGScg en0 **0/1 link#21 UCSIg utun7 ** default link#21 UCSIg utun7 10.2.0.130 10.2.0.130 UH utun7 127 127.0.0.1 UCS lo0 127.0.0.1 127.0.0.1 UH lo0 **128.0/1 192.168.29.1 UGSc en0 128.0/1 link#21 UCSI utun7 **