I have the following scenario in my VPN app.
When app is configured with split tunneling, the vpn dns nameservers are defined in /etc/resolver/example.com (example.com is the domain to be resolved through tunnel) and secondary vpn dns server is configured as 8.8.8.8 (google public dns server) and primary as 3.92.179.203.
With the following configuration the dns request are not routed through the tunnel, when I try to ping example.com it does not use 3.92.179.203. Explicit routes are added in the routing table to route the traffic to 3.92.179.203 via VPN interface.
It used to work on older macOS versions 12.6 from 14.4 it seems broken system behaves differently when 8.8.8.8 is defined as a vpn nameserver. DNS requests does not go through tunnel it is resolved outside tunnel.
If I use 9.9.9.9 or 1.1.1.1 or anyother nameserver other than 8.8.8.8 then it all works correctly.
OK. In that case I’m not going to be able to help you. DTS doesn’t support legacy VPN techniques, and we recommend that you instead create an NE provider.
Your original post is a good example of why we have this policy. The /etc/resolv.conf
mechanism is a compatibility measure of Apple platforms. The true DNS configuration is managed by the various plug-ins within configd
. NE providers use API to apply their DNS configuration, and the system manages that in a coherent way. The behaviour you get when you start modifying resolver configuration files is unspecified exactly because it’s there solely to support compatibility.
A similar situation applies to the routing table. It is also managed by configd
, and if you manipulate it ‘behind the back’ of configd
you’ll run into problems.
You are, of course, free to continue down this path on your own, but it’s not a road I can join your on.
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"