DNS Forwarder Does Not Seem to Exist in VMware Fusion 12 on Big Sur

[Switchfoot]

I upgraded to Big Sur RC2 with VMware Fusion 12 and I've noticed that the networking mostly works, but the DHCP provided DNS server/forwarder does not seem to function properly. I've tried manually querying it with dig, but it just times out. I'm not actually sure if this is a limitation of Apple's vmnet implementation, a bug, or some leftover config from the upgrade mucking things up.

Is it not supposed to be pointing at the default gateway like it did previously or are there some other things I should be investigating? FWIW, this is running on a Fedora VM using NAT on a MacBook Pro 16". Changing the networking from vmxnet3 or e1000 doesn't do anything to change this nor does resetting the networking setup via vmnet-cli.

[bharatrajagopal]

Hi

Cisco AnyConnect VPN includes OpenDNS which starts dnscrypt in port 53

https://www.cisco.com/c/en/us/support/docs/security/anyconnect-secure-mobility-client/200940-Anyconn...

These instructions didn't work for me:
https://support.umbrella.com/hc/en-us/articles/230561067-Umbrella-Roaming-Client-Manually-Disabling-... 

So this is what I do

First check

sudo lsof -i -P -n | grep :53 

mDNSRespo 213 _mdnsresponder 6u IPv4 0xecf7a360ee53b4b3 0t0 UDP *:5353
mDNSRespo 213 _mdnsresponder 7u IPv6 0xecf7a360ee539a8b 0t0 UDP *:5353
com.cisco 281 root 29u IPv4 0xecf7a3610031c343 0t0 UDP 192.168.1.18:65255->192.168.1.1:53
dnscrypt- 1531 nobody 45u IPv4 0xecf7a360eb2fd79b 0t0 UDP 127.0.0.1:53
dnscrypt- 1531 nobody 46u IPv4 0xecf7a360f325b9a3 0t0 TCP 127.0.0.1:53 (LISTEN)

These instructions don't work for me, and I worked out the following instead

to turn off OpenDNS and VPN run

sudo launchctl unload /Library/LaunchDaemons/com.cisco.anyconnect.vpnagentd.plist

When you run
sudo lsof -i -P -n | grep :53
output: (no dnscrypt)
mDNSRespo 213 _mdnsresponder 6u IPv4 0xecf7a360ee53b4b3 0t0 UDP *:5353
mDNSRespo 213 _mdnsresponder 7u IPv6 0xecf7a360ee539a8b 0t0 UDP *:5353
com.cisco 281 root 29u IPv4 0xecf7a3610031c343 0t0 UDP 192.168.1.18:65255->192.168.1.1:53


Once this is done start your VM - DNS resolution will now work

then 

sudo launchctl load /Library/LaunchDaemons/com.cisco.anyconnect.vpnagentd.plist

sudo lsof -i -P -n | grep :53
mDNSRespo 213 _mdnsresponder 6u IPv4 0xecf7a360ee53b4b3 0t0 UDP *:5353
mDNSRespo 213 _mdnsresponder 7u IPv6 0xecf7a360ee539a8b 0t0 UDP *:5353
mDNSRespo 213 _mdnsresponder 15u IPv4 0xecf7a360f30ffa8b 0t0 UDP *:53
mDNSRespo 213 _mdnsresponder 56u IPv6 0xecf7a360f656f913 0t0 UDP *:53
mDNSRespo 213 _mdnsresponder 57u IPv4 0xecf7a360fc4fa203 0t0 TCP *:53 (LISTEN)
mDNSRespo 213 _mdnsresponder 65u IPv6 0xecf7a360f9f680ab 0t0 TCP *:53 (LISTEN)
com.cisco 281 root 29u IPv4 0xecf7a3610031c343 0t0 UDP 192.168.1.18:65255->192.168.1.1:53

Your VM DHCP continues to work until you turn VPN on the host - the only way around it is set DNS on the VM to 8.8.8.8 or the like while vpn on the host is on - however then you cannot start VPN inside the VM. Tried both NAT and bridged mode and noticed this behaviour

Also note that when you start Cisco AnyConnect - you will see that it says Roaming security is active but there will be a big Red Cross beside it. VPN however works when turned-on.

If you switch your VM from NAT to bridged and then start VPN on the host it automatically turns on dnscrypt
sudo lsof -i -P -n | grep :53 
mDNSRespo 213 _mdnsresponder 6u IPv4 0xecf7a360ee53b4b3 0t0 UDP *:5353
mDNSRespo 213 _mdnsresponder 7u IPv6 0xecf7a360ee539a8b 0t0 UDP *:5353
com.cisco 281 root 29u IPv4 0xecf7a3610031c343 0t0 UDP 192.168.1.18:65255->192.168.1.1:53
com.docke 1077 bharat_rajagopalan@uk.ibm.com 17u IPv4 0xecf7a360eb2fd79b 0t0 UDP *:53878
com.docke 1077 bharat_rajagopalan@uk.ibm.com 21u IPv4 0xecf7a360ed989343 0t0 UDP *:53559
dnscrypt- 1963 nobody 44u IPv4 0xecf7a360ed989913 0t0 UDP 127.0.0.1:53
dnscrypt- 1963 nobody 45u IPv4 0xecf7a360f49f2143 0t0 TCP 127.0.0.1:53 (LISTEN)

It would be nice if Vmware could find a way to just use dnscrypt for DNS resolution so that we don't need to go through these hacks

Bharat

[ForPete]

This is the problem:

Before starting a VM:

sudo lsof -i -P -n | grep :53 gives:
mDNSRespo 284 _mdnsresponder 6u IPv4 0xd208d23dd3adab9d 0t0 UDP *:5353
mDNSRespo 284 _mdnsresponder 7u IPv6 0xd208d23dd3ada8b5 0t0 UDP *:5353


After starting a VM:

sudo lsof -i -P -n | grep :53 gives:
mDNSRespo 284 _mdnsresponder 6u IPv4 0xd208d23dd3adab9d 0t0 UDP *:5353
mDNSRespo 284 _mdnsresponder 7u IPv6 0xd208d23dd3ada8b5 0t0 UDP *:5353
mDNSRespo 284 _mdnsresponder 44u IPv4 0xd208d23ddce4b73d 0t0 UDP *:53
mDNSRespo 284 _mdnsresponder 45u IPv6 0xd208d23ddce4ab9d 0t0 UDP *:53
mDNSRespo 284 _mdnsresponder 46u IPv4 0xd208d23de09f169d 0t0 TCP *:53 (LISTEN)
mDNSRespo 284 _mdnsresponder 47u IPv6 0xd208d23deb2b024d 0t0 TCP *:53 (LISTEN)

So it starts a DNS server on the host for VM's using NAT.
This works as long nothing else is using this port as well.

[tomeq82]

Hi, 

I can confirm those findings. I'm using BigSur 11.2, latest Fusion and corporate tools running on macOS. 

The problem is mainly with running DNS resolver Cisco Umbrella, spawned via Cisco AnyConnect. But this happens for ANY runnning resolver on host system eg. stubby for DNSoTLS resolution etc. 

The only solution was to uninstall any DNS resolvers running on host OS, then NAT networking on guest os could work. 

This is easily visible when doing some traffic dumps... it's a pity that it is not addressed by vmWare as I would say they are networking basics right now.... 

p.s: If you want to uninstall Umbrella - go to /opt/cisco/anyconnect/bin/ and sudo ./umbrella_uninstall.sh

That will remove dnscrypt-proxy from host os (keep in mind that from now on you are on your own when resolving DNS over TLS, eg. you will end with non encrypted queries if your upstream DNS doesn't provide them!)

[neonsteve]

I just wanted to pile on here and say if you are using dns-heaven for command line tools that don't support the OS resolver, this same issue occurs with vmware fusion 12 on Big Sur.

https://github.com/greenboxal/dns-heaven

The workaround described up thread where you stop the service, start vmware fusion, then start the service does indeed work.