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.