We have a PacketTunnelProvider as a SystemExtension supporting macOS Big Sur and above. We supply below config as part of tunnel settings to bring up the tunnel: Remote Address: 240.0.0.2 DNS Servers: [240.0.0.3] Match Domains: [A list of FQDNs] IPv4 Address: 240.0.0.1 and subnet mask 255.255.255.255 IPv4 Include Routes: 240.0.0.1 with subnet mask 255.192.0.0 Once we provide these settings, a utun is created (utun4), the routes are setup as in below screenshot and tunnel is connected. My first question is, why is there duplicate entry for my tunnel address? AFAIK, tunnel address is by default part of exclude routes. Next when I access an FQDN, we get the DNS request in our provider and respond to it with an IP of 240.0.0.5 and start getting data packets. If we check route table after this, there is an entry for the new IP we have responded with: So my next question is, why is the new IP (240.0.0.5) setup against our utun4 when there is already 240.0.0/10 setup against our utun4 covering this IP? Also, if you notice, the duplicate entry for tunnel address is gone, not sure why. Nothing changed in tunnel settings. Next, I tried to disconnect and reconnect the provider from Network Preferences and tunnel came up with same tunnel settings but a new utun (utun7) got created and route setup looked like below screenshot: and here are the utuns from ifconfig So the next question arises is, does PacketTunnelProvider create new utun every time it gets disconnected and reconnected? And if it does, why is not the previous stale utun destroyed? Why are my IP settings still pointing to old utun in route table? Next, I tried to access the FQDN again, resulting in a DNS request which was responded with IP 240.0.0.5. After that, the route table looks like this: Now, we can see a duplicate entry for 240.0.0.5 on utun4 as well as utun7. Why? Couldn't that cause confusion or even route conflicts? Please note, so far we have not had any functional issues due to confusing or even conflicting route setups. After disconnect and reconnect, all the traffic goes correctly via utun7 even though there is old and stale utun4 with conflicting routes. Another note: All the route outputs are generated using netstat -r -f inet.

In our macOS SystemExtension, we are using Network.framework for creating web socket connection to our remote WSS server. We provide authentication token in cookies of the connection and websocket server validates it before upgrading the connection from HTTP to WebSocket. If the cookie is invalid, server returns 403 HTTP status code and closes the connection. When server returns 403, in Big Sur and Monterey, we get state update of failed(let error) where error is NWError.posix(.ECONNABORTED). However, in Ventura, we are getting state waiting(let error) where error is NWError.posix(.ECONNABORTED). As per documentation, waiting state should be received if there is any network error in establishing the connection and connection goes into waiting for network path change. But in this case, TCP connection to server is established, HTTP headers are received and validated by server and then get rejected. So shouldn't this result into connection failed instead of waiting? This behaviour has only changed on Ventura. On Big Sur and Monterey we still get failed with error.