VPN / DNS Issues With macOS Ventura

Here's a potential workaround I have found, tested on 13.3, unfortunately this wouldn't necessarily work at a public place but hopefully helps someone.

I recently discovered the bug its triggered when the DNS assigned to the interface providing internet access has a Public DNS . Meaning the interface gets a public address for its DNS via DHCP or statically . However if you have an internal DNS the problem goes away.

For example, say im at home and my ISP router gives my laptop the following DHCP settings

IP 192.168.100.101

Subnet 255.255.255.0

Gateway 192.168.100.1

DNS 75.75.75.75 <-- Public DNS

When I connect to my work VPN I will not be able to properly resolve work internal names.

nslookup will show the correct response but other applications won't including ping, trace route, safari an others.

However if your router supports DNS resolution (most do) manually change the DNS to it in my case its the same as my gateway and would look like this:

IP 192.168.100.101

Subnet 255.255.255.0

Gateway 192.168.100.1

DNS 192.168.100.1 <-- Private DNS

After the change I reconnected to my VPN and DNS resolution works over the VPN as expected for internal names.

Why in the world does OSX gets confused when using a Public DNS server is beyond me but I hope this helps someone.

We have also contacted Apple via our enterprise agreement and I am sharing my findings, hopefully the issue will get some traction.

I spoke to Apple Enterprise Support on March 14 and gave them as much information regarding this issue as I possibly could. Logs, screen captures, demonstrations of the issue. I shared them support forum posts, reddit posts, MacRumors posts, VPN company support forum posts (including from major security vendors like FortiNet).

And yet, some how 2 weeks later they still "were not aware of an issue."

This tells me that Apple did nothing with everything I gave them because they don't care.

ge-apple wrote:

I spoke to Apple Enterprise Support on March 14 and gave them as much information regarding this issue as I possibly could. Logs, screen captures, demonstrations of the issue. I shared them support forum posts, reddit posts, MacRumors posts, VPN company support forum posts (including from major security vendors like FortiNet).

And yet, some how 2 weeks later they still "were not aware of an issue."

This tells me that Apple did nothing with everything I gave them because they don't care.

Perhaps there is another explanation. I'm sure that Apple doesn't care about support forum posts, reddit posts, MacRumors posts, or VPN company support forum posts. Mention any of that and your report goes straight to the bit-bucket, as it should.

If you had specific information about your own experiences, such as logs, screen captures, and demonstrations, then they will pay attention to that. But I strongly suggest you limit the information you provide to your own experiences. If it sounds like you did your own "internet research", that's another one-way trip to the bit-bucket. People with jobs have no time for the internet.

Finally, and most importantly, this thread is 5 pages long. It was started in October of last year. Early posts consisted of people complaining that their VPNs were functioning correctly. Since then, it's become a dumping ground for any random complaints about DNS, mostly in an enterprise context, which can be really complicated. Any statements that anyone could make about "this issue" are self-evidently invalid. There are multiple issues. Some are totally invalid. Some are obviously related to configuration problems. To expect Apple to do anything, in two weeks no less, is completely outside the bounds of reality.

There is a good chance that whatever problems you are experiencing are, in fact, configuration problems. If you start your own thread discussion your own specific problem, then people will help you resolve it. This thread is the bit-bucket, the sewer of the Apple Support communities. You can contribute as much content as you want. Just don't expect anyone to drink from it. The only meaningful responses you will get are replies like this, suggesting that you leave the sewer if you want to get help.

What I have shown was that for some reason Safari will use the custom (internal) DNS we use every other time the page is loaded.

This is what our devices at work get DNS wise via DHCP:

internal.dns.server

8.8.8.8

4.4.4.4

A web site directed to by the internal DNS loads fine in Safari on the first attempt, but if I reload the page it fails to load if I reload again it loads, and on.

This is what caught some attention.

Also mentioned that if I manually add internal.dns.server as the DNS server for the network interface in use, i.e. so it’s the only DNS server in the list, then the internal web page loads in Safari every time.

Early posts consisted of people complaining that their VPNs were functioning correctly. Since then, it's become a dumping ground for any random complaints about DNS, mostly in an enterprise context, which can be really complicated.

An important thing to remember is that this is a change in behavior from Monterey to Ventura with no other external changes.

The same via DHCP deployed DNS settings behaves differently in Ventura compared to Monterey whether VPN is involved or not.

Here are my latest updates...

VP of IT: The issue still is not Apple. It is that we need an internal address to resolve in OpenDNS

VP of IT: Moreover why is OpenDNS even in there when it is not receiving any queries

Manager of ITOps: It is considered bad security practice to put internal entries in public DNS

VP of IT: Correct

VP of IT: OpenDNS should only be when we are external…. Yes?

Manager of ITOps: Therefore we cannot have OpenDNS resolve internal addresses.

Manager of ITOps: The problem IS Apple and not honoring the DNS server order from the DHCP settings.

Manager of ITOps: The OpenDNS servers were added they solely to account for loss of access to internal DNS servers.

Manager of ITOps: It was primarily necessary in offices where there was no on-site domain controller for when the WAN would become unavailable.

Me: As far as Apple “knows” there is no issue with macOS. They wanted to blame our MDM and will not troubleshoot further until we test after removing our MDM. I spoke to Tech1 who is going to remove our MDM and reinstall macOS to rest further. Once that has been completed I will report back to Apple Support.

VP of IT: Stop spinning our wheels with Apple. It does not matter.

Manager of ITOps: Correct, if we are willing to accept that in a network failure, there will be NO DNS resolution in offices w/o an onsite server. Then we should plan on never putting OpenDNS back in the list.

VP of IT: As long as you are fully redundant for internal resolvers then you are okay.

Manager of ITOps: that is the issue, in some offices, we are not fully redundant.

VP of IT: Well then that is more the issue.

VP of IT: DNS should have at least one resolver locally and a backup within our data center

VP of IT: Or we need to rethink the OKTA login process and it calling oktalogin.xxxxx.com

TLDR: We are going to stop using OpenDNS and have redundancy in each office and "ignore" The problem is Apple and that they are not honoring the DNS server order from the DHCP settings.

leon_is_awesome wrote:

Hi,

I have been having this problem also but I just solved it. I actually only joined to post the solution

Indeed the /etc/resolv.conf is over-written props to the user who pointed that out on page 3). For me it was overwritten with an internal 10.x address so obviously DNS was failing.

What is causing the overwrite is after upgrading apple turns on by default limit ip tracking.

01) Go to settings

02) Go to networks

03) Click details next to the network name In my case my wireless

04) Turn off limit ip tracking

05) Try your vpn again

That one thing fixed the automatic overwriting of the conf file.

I work in cloud security arch and while I am a big believer in secure defaults it is obnoxious to roll something like that out breaking people's vpns without some kind of warning.

Good luck to everyone!

Hi Leon,

Do you know of a bash script (if there is one) that we can use to push and turn off limit ip tracking? In our case we were not using a VPN as we were testing in office.

"Turn off limit ip tracking" didn't make a difference for mer when connected via my work VPN which gives out internal.dns.server and Google's 8.8.8.8 via DHCP when connecting to the VPN. None of the DNS names configured for the internal DNS server resolves. If I (since I'm an admin) change so that when connected via the VPN only the internal DNS is given out the custom DNS names resolves fine.

So, it's when having more than one DNS problems start to happen, at least for me.

One more person experiencing this problem, chiming in.

I have a dedicated dhcp/dns server running dnsmasq. It was all fine when it offered only itself as the dns server. When I added a secondary dns public server to the list of dns servers offered to its dhcp clients, all of sudden MacOS 13.3.1 failed to resolve address when using command line utilities like "ping" and "ssh" would not work with local domain names. Diagnostic utilities like "nslookup", "dig", and "scutil -r" would work. Chrome and Safari also work. My older macs, with no unsupported OS's, all worked fine. My windows computers worked fine. My Chromebooks worked fine. The only problem is with my MacOS 13.3.6 system.

I resovled it by adding a /etc/resolver/lan, where "lan" is the my local network doman name", and declared the local name server in that resolver file. But hardcoding the dns like that defeats the purpose of using dhcp to distribute the name server address.

Having MacOS M2 with 13.3.1, I have (I had) the same issue with all VPN connections (regardless the system used, at least with SonicWall, Fortinet, WatchGuard, Ivanti).

I found a quite dirty but worky solution: after the connection being established, and the /etc/resolv.conf being updated, I explicitly set the DNS back to something public.

For example:

networksetup -setdnsservers "Wi-Fi" 8.8.8.8

That did the thing for all aforementioned VPN clients.

Guys, I don't know why VPN is involved here - I'm having the problem with just DNS on a new Mac Mini that came with Ventura installed (so I can't downgrade).

DNS resolution doesn't work but I can ping addresses (including DNS servers such as 1.1.1.1 or 8.8.8.8) and as others noted, dig is able to resolve domain names.

For a while, I was able to solve this by killing the mDNSResponder and helper but after the most recent Ventura update, even that only worked sometimes.

No problems with any other Mac, Windows or Linux box on my LAN

With all due respect, @nvssm, your issue is different from what is being discussed here. In our case, DNS resolution works both with and without VPN, except that at some point, Apple starts using the DNS servers provided by the outside connection (WiFi, ethernet, etc.) instead of the ones provide by the VPN which breaks resolution of names for internal hosts.

If your internal network is using a .local domain, make sure, when attempting to reach resources on it, you use the full domain name.

For example, when trying to access a share called "share" on a server named "server" on the domain "company", the SMB share would be smb://server.company.local/share not smb//server.company/share

Now that Mac OS 14 has been released: Was it fixed? With 13.6.1 it is still not working.

For me I had to use the internal DNS server as the DNS on the Wifi connection, as the TUN connection would have the correct DNS servers, but still the system would only query the Wifi DNS server only, instead of using the VPN one's instead.

Thanks a lot :)

Has anyone actually got any support from Apple? Seems like the issue is still present with Sonoma. It seems like when connected to the IKEv2 VPN, the local DNS queries are going through 127.0.0.1 and don't actually route properly. If I do nslookup and specific the server manually, it queries fine.