Contributor
Contributor

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

Jump to solution

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.

Tags (2)
1 Solution

Accepted Solutions
Enthusiast
Enthusiast

Sigh...  I had a very in-depth response with my solution typed up, and clicking the "permalink" (which I assumed would get me a link to just my reply) caused the message to be deleted!   I'll try to re-create it...

The problem was indeed related to software that is already on my system.  My prior post got me thinking about verifying that a DNS server is indeed listening.

On my non-working laptop (with VMware Fusion 12 running):

% netstat -an | grep LISTEN | grep "*.53"
tcp6 0 0 *.53 *.* LISTEN

On the working clean Big Sur install (with VMware Fusion 12 running)

% netstat -an | grep LISTEN | grep "*.53"
tcp6 0 0 *.53 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN

 

This sure looks like a problem.   With a working host, there is indeed something listening on the DNS port for IPv4.  For my non-working host, it's only listening on IPv6.  Time to dig a bit deeper:

Non-working host:

% sudo lsof -i -P -n
...
dnsmasq 15721 nobody 4u IPv4 0xbb40ee7a9140f6dd 0t0 UDP 127.0.0.1:53
dnsmasq 15721 nobody 5u IPv4 0xbb40ee7aaa0a21dd 0t0 TCP 127.0.0.1:53 (LISTEN)

 

Working clean Big Sur host:

% sudo lsof -i -P -n
...
mDNSRespo 237 _mdnsresponder 39u IPv4 0xbb40ee7a9275de1d 0t0 UDP *:53
mDNSRespo 237 _mdnsresponder 42u IPv6 0xbb40ee7aa04bcf95 0t0 UDP *:53
mDNSRespo 237 _mdnsresponder 43u IPv4 0xbb40ee7a9b7c7e6d 0t0 TCP *:53 (LISTEN)
mDNSRespo 237 _mdnsresponder 45u IPv6 0xbb40ee7a95d47d8d 0t0 TCP *:53 (LISTEN)

 

Yes, my non-working (with regard to DNS on a NAT VM) host has dnsmasq running on it.  But only on the localhost/loopback adapter.  Up until Big Sur, this wasn't a problem.  VMware Fusion took care of its own network stuff for the most part, so it is agnostic to any host-level thing already bound to port 53.  It bound its own DNS server to its own NAT adapter, and everybody was happy.

Now, starting with Big Sur, VMware Fusion leverages more OS-level networking stuff.  So to implement a DNS server on its NAT adapter, it asks the host OS to start a DNS server.  The problem here is that mDNSResponder is greedily attempting to bind port 53 on every address.  And in my case, because I have something using port 53 on loopback, mDNSResponder fails to bind port 53 on any address.

If I stop the dnsmasq service (in my case via sudo launchctl unload /Library/LaunchDaemons/org.macports.dnsmasq.plist), everything works perfectly.  Any VM using NAT now has the ability to look up domain names using the DNS server provided by DHCP.

Suggestion for a VMware-level fix (i.e. in an upcoming version of VMware Fusion):

  • When using mDNSResponder to implement a NAT-level DNS server, attempt to bind only to the adapter/address that is being used by VMware for NAT (assuming this is possible).  This would ensure that there will be no conflicts with whatever way the host OS is configured to do networking.

Suggestions for a User-level fix (i.e. for us mortals before a fix can be released), either:

  • Before launching VMware Fusion, be sure that nothing is binding port 53 on any address.
    After a VM has been started, you can probably re-start whatever was using port 53 again. At least I can in my case where dnsmasq was bound to 127.0.0.1:53
    Though note that starting any new VM after you've re-occupied port 53 will break DNS for every running VM at this point.
  • Configure every VM guest to use a not-on-host DNS server.  (e.g. 1.1.1.1 or 8.8.8.8)

 

View solution in original post

20 Replies
VMware Employee
VMware Employee

Hi Switchfoot

 

Does this issue occur for all the sites or a certain address? say dig example.com got timeout. Did you have VPN connected on your Big Sur host?

0 Kudos
Contributor
Contributor

Hi,

Based on my limited testing (I ran dig on a few major sites: google.com, bing.com, amazon.com) NAT currently fails to resolve anything unless you give it different, known working, DNS server to target (8.8.8.8 or 1.1.1.1 work fine). In Bridged mode one can see the DNS resolve...sorta. I am primarily testing via a Fedora 33 and in Bridged mode with the VMware provded DNS server, one would see OpenSSL errors. For instance, attempting to run `dnf upgrade` triggers messages that include this error: `[OpenSSL SSL_read: error:1408F119:SSL routines:ssl3_get_record:decryption failed or bad record mac, errno 0]`. Similarly, this doesn't happen if the system is told to use a different DNS server.

None of this is over VPN.

0 Kudos
Enthusiast
Enthusiast

The problem isn't related to any VPN present on the host.  The problem is that NAT on VMware Fusion 12 running on Big Sur doesn't have a working DNS server/forwarder.

On a Catalina system with VMware Fusion 12.0:
/Library/Preferences/VMware\ Fusion/vmnet8/nat.conf specifies useMacosVmnetVirtApi = 0
- % sudo ./vmnet-cli -v --status
Password:
Commands specified: status
Features configured on vmnet0 are: Bridge
Features configured on vmnet1 are: subnet DHCP HostOnlyAdapter
Runtime features on vmnet1 are: DHCP HostOnlyAdapter
DHCP service on vmnet1 is running
Hostonly virtual adapter on vmnet1 is enabled
Features configured on vmnet8 are: subnet DHCP NAT HostOnlyAdapter
Runtime features on vmnet8 are: DHCP NAT HostOnlyAdapter
DHCP service on vmnet8 is running
NAT service on vmnet8 is running
Hostonly virtual adapter on vmnet8 is enabled
All the services configured on all the networks are running
(emphasis mine)

- A VM that uses NAT can use the DNS server that the VMware DHCP server suggests

 

On a macine that is running Big Sur with the very same VMware Fusion 12 version:

/Library/Preferences/VMware\ Fusion/vmnet8/nat.conf specifies useMacosVmnetVirtApi = 1
- % sudo ./vmnet-cli -v --status
Commands specified: status
Features configured on vmnet0 are: Bridge
Features configured on vmnet1 are: subnet NAT HostOnlyAdapter
NAT service on vmnet1 is not running
Hostonly virtual adapter on vmnet1 is disabled
Features configured on vmnet8 are: subnet DHCP NAT HostOnlyAdapter
DHCP service on vmnet8 is not running
NAT service on vmnet8 is not running
Hostonly virtual adapter on vmnet8 is disabled
Features configured on vmnet9 are: subnet
Features configured on vmnet10 are: subnet
Some/All of the configured services are not running
(emphasis mine)

- A VM that uses NAT will never hear a response from DNS requests to the IP that VMware suggests via DHCP should be used for name resolution.

What can we conclude from this?

  • Something changed with how the NAT networking is implemented starting with Big Sur. (Based on observing the difference of useMacosVmnetVirtApi in the nat.conf file.
  • vmnet-cli reports that on Big Sur, not all configured services are running.
  • VMs using NAT on Big Sur fail to be able to do DNS lookups.

Anybody working at VMware with access to a Big Sur machine should be able to recreate this quite easily. And hopefully roll out a fix.

VMware Employee
VMware Employee

Hi

Thanks for your update. But I was not able to reproduce the DNS issue. I installed a Fedora 33 on BigSur and use NAT network , I got the following output for dig command: 

$ dig yahoo.com

; <<>> DiG 9.11.23-RedHat-9.11.23-1.fc33 <<>> yahoo.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54315
;; flags: qr rd ra; QUERY: 1, ANSWER: 6, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 65494
;; QUESTION SECTION:
;yahoo.com. IN A

;; ANSWER SECTION:
yahoo.com. 1127 IN A 74.6.231.21
yahoo.com. 1127 IN A 74.6.143.26
yahoo.com. 1127 IN A 74.6.231.20
yahoo.com. 1127 IN A 98.137.11.164
yahoo.com. 1127 IN A 98.137.11.163
yahoo.com. 1127 IN A 74.6.143.25

;; Query time: 392 msec
;; SERVER: 127.0.0.53#53(127.0.0.53)
;; WHEN: Mon Nov 16 19:56:26 EST 2020
;; MSG SIZE rcvd: 134

Could you try to restart the Fedora VM?

For the output of command on Big Sur,

$sudo ./vmnet-cli -v --status

the output of dhcp service shows the result of dhcp service provided by Fusion; but on BigSur we use build-in dhcp service.

0 Kudos
Enthusiast
Enthusiast

OK, so then perhaps the vmnet-cli -v --status stuff was a red herring.  But I think we can agree that multiple people are having trouble with NAT DNS on Big Sur.  Plenty more in this thread:  https://communities.vmware.com/t5/VMware-Fusion-Discussions/macOS-Big-Sur-Fusion-12-NAT-no-internet-...

This is all VMs.  Linux, Windows, anything that talks ethernet.  There is no answer from any DNS server at what the DHCP settings suggests the VMs should use.  In my case, 172.16.77.1

With a clean Big Sur installation in a VM (yes, nested virtualization, to be able to achieve my test), I do see that NAT DNS is working, though.  So perhaps there's some problem that upgraded-to-Big-Sur and/or upgraded to VMware Fusion 12 machines have?

0 Kudos
Contributor
Contributor

No matter what I do, this the NAT provided DNS forwarder does not work, not even on a fresh VM running from a Fedora 33 Live CD. Unless I explicitly set a known working DNS resolver, DNS resolution is not functioning properly.

Do you happen to know in your test what NetworkManager is showing as the DNS entry? Since 127.0.0.53 is a loopback address, so it's likely something going on with systemd-resolved and I'm just wondering if there's some sorta fallback DNS it might be resorting to. Are you able to get a successful dig response if you explicitly query the VMware DNS forward address/default gateway?

0 Kudos
Enthusiast
Enthusiast

@Switchfoot The use of 127.0.0.53 is simply an artifact of a modern systemd-using Linux system. systemd hides what's going on with DNS with a layer of abstraction. So sadly the output that @nancyz has provided doesn't prove that their VM has working NAT DNS without trickery. But I have no reason to not believe it. FWIW, if one wants to see what DNS server is actually being used by a systemd-using system, they'd have to look at /run/systemd/resolve/resolv.conf. dig or nslookup would simply convey that the request was being sent to localhost and the response received (if any) from there.

For troubleshooting, I've even duplicated the network configuration in my working clean Big Sur machine to my not-working primary laptop, but that hasn't helped.

Attached to this message is a screenshot from a virtual machine running on my host. You can see that the VM (192.168.180.2) is attempting to contact 192.168.180.1:53 to get the answer to what google.com resolves to. And the response is udp port domain unreachable, which I parse as meaning that there's no reachable DNS server running on 192.168.180.1. 

 

0 Kudos
Enthusiast
Enthusiast

@Switchfoot The use of 127.0.0.53 for DNS lookups is simply an artifact of using a modern systemd-enabled Linux machine. DNS requests go to localhost (systemd), and then systemd asks the resolvers it knows about how to resolve the domain name. Sadly, this means that the output posted from @nancyz does prove that the DNS is being provided by the VMware NAT adapter without any trickery involved. But I have no reason not to believe it. FTR, to see the actual DNS used by a systemd-enabled system, you'd have to look at /run/systemd/resolve/resolv.conf.

As a troubleshooting step, I tried duplicating the network config of a working clean install (albeit in a VM itself) of Big Sur machine using vmnet-cfgcli exportconfig and importconfig to see if that'd help, but it did not.

Attached to this message is a screenshot that shows the DNS configuration, and when the nslookup occurs, the response from the NIC at 192.168.180.1 is udp port domain unreachable. Which I parse as meaning that there is no DNS server running on 192.168.180.1, which is the VMware NAT adapter.

0 Kudos
Enthusiast
Enthusiast

Now compare the above output with a clean Big Sur installation in a VM. The VMware network configuration is identical, due to the exported/imported configuration described above.  But the difference here is that the DNS server on 192.168.180.1 does answer the request.  In the working case, there is a DNS server is listening on 192.168.0.1.

The million-dollar question is: Why the difference?

Both are the same version of Big Sur.  Both are the exact same version of VMware Fusion 12.0, installed from the same DMG. Both are running the exact same version of CloneZilla as a live CD.

Where the differences start is that the working clean Big Sur machine has network connectivity provided by a virtual ethernet adapter, where the DNS server of the "host" is manually set to 8.8.8.8 to work around this bug.  My non-working actual laptop has:

  • lived through several versions of OS X before getting to Big Sierra
  • lived through several versions of VMware Fusion before arriving at 12.0
  • DNS
  • a number of applications installed on it, as compared to the working install, which has nothing other than Big Sur.

Everything I've tried so far has been based on hunches and educated guesses.  But I guess it'd be nice to know specifically what I might need to look for.

0 Kudos
Enthusiast
Enthusiast

"a number of applications installed on it, as compared to the working install, which has nothing other than Big Sur."

 

Ok, I got it!!

My last message got me thinking about looking into verifying what was actually listening on the DNS port.  First check: netstat

Non-working laptop:
% netstat -an | grep LISTEN | grep "*.53"
tcp6 0 0 *.53 *.* LISTEN

Wait a minute... only IPv6?

 

Working VM:
% netstat -an | grep LISTEN | grep "*.53"
tcp6 0 0 *.53 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN

 

OK.  Here's a smoking gun.  An obvious related difference is that in the working clean machine, there's something listening on port 53 using IPv4 on every interface.  Let's ignore the fact that it's TCP for now, as a DNS server can listen on both TCP and UDP.

Now let's dig deeper... why is there no listener on 53 on my host?  My non-working (as far as VMware Fusion NAT DNS is concerned) laptop uses dnsmasq, listening on only 127.0.0.1.  Let's see:

% sudo lsof -i -P -n
...
dnsmasq 15721 nobody 4u IPv4 0xbb40ee7a9140f6dd 0t0 UDP 127.0.0.1:53
dnsmasq 15721 nobody 5u IPv4 0xbb40ee7aaa0a21dd 0t0 TCP 127.0.0.1:53 (LISTEN)

 

Now let's compare this to the clean Big Sur machine, where NAT DNS works:

% sudo lsof -i -P -n
...
mDNSRespo 237 _mdnsresponder 39u IPv4 0xbb40ee7a9275de1d 0t0 UDP *:53
mDNSRespo 237 _mdnsresponder 42u IPv6 0xbb40ee7aa04bcf95 0t0 UDP *:53
mDNSRespo 237 _mdnsresponder 43u IPv4 0xbb40ee7a9b7c7e6d 0t0 TCP *:53 (LISTEN)
mDNSRespo 237 _mdnsresponder 45u IPv6 0xbb40ee7a95d47d8d 0t0 TCP *:53 (LISTEN)

 

Well here's the problem!  Before Big Sur, VMware Fusion did its own DNS stuff, so it was unaffected by a service already bound to port 53 on the host.  But starting with Big Sur, VMware leverages os-level DNS dispatching.  The problem here is that the OS-level mDNSResponder handling of DNS requests appears to want to bind to every address.  And if something has already bound port 53, even just for the loopback address, this greedy attempt to bind port 53 everywhere results in port 53 being bound nowhere.  So as described above, any NAT-enabled VM in such a situation will have nothing to answer its DNS requests.

If it's possible, a VMware-level fix would be to cause mDNSResponder to bind port 53 only on the network interfaces that VMware has configured / is using. That way, VMware Fusion should be guaranteed to not conflict with any network configuration that the machine operator has configured.

A user-level fix (until this problem is resolved) should be either:

  • Configure all VMs to explicitly configure a not-on-host DNS server, as has been discussed in this and other threads.
  • Before launching VMware Fusion, ensure that nothing on your host is already bound to port 53 (DNS) 

 

0 Kudos
Enthusiast
Enthusiast

Sigh...  I had a very in-depth response with my solution typed up, and clicking the "permalink" (which I assumed would get me a link to just my reply) caused the message to be deleted!   I'll try to re-create it...

The problem was indeed related to software that is already on my system.  My prior post got me thinking about verifying that a DNS server is indeed listening.

On my non-working laptop (with VMware Fusion 12 running):

% netstat -an | grep LISTEN | grep "*.53"
tcp6 0 0 *.53 *.* LISTEN

On the working clean Big Sur install (with VMware Fusion 12 running)

% netstat -an | grep LISTEN | grep "*.53"
tcp6 0 0 *.53 *.* LISTEN
tcp4 0 0 *.53 *.* LISTEN

 

This sure looks like a problem.   With a working host, there is indeed something listening on the DNS port for IPv4.  For my non-working host, it's only listening on IPv6.  Time to dig a bit deeper:

Non-working host:

% sudo lsof -i -P -n
...
dnsmasq 15721 nobody 4u IPv4 0xbb40ee7a9140f6dd 0t0 UDP 127.0.0.1:53
dnsmasq 15721 nobody 5u IPv4 0xbb40ee7aaa0a21dd 0t0 TCP 127.0.0.1:53 (LISTEN)

 

Working clean Big Sur host:

% sudo lsof -i -P -n
...
mDNSRespo 237 _mdnsresponder 39u IPv4 0xbb40ee7a9275de1d 0t0 UDP *:53
mDNSRespo 237 _mdnsresponder 42u IPv6 0xbb40ee7aa04bcf95 0t0 UDP *:53
mDNSRespo 237 _mdnsresponder 43u IPv4 0xbb40ee7a9b7c7e6d 0t0 TCP *:53 (LISTEN)
mDNSRespo 237 _mdnsresponder 45u IPv6 0xbb40ee7a95d47d8d 0t0 TCP *:53 (LISTEN)

 

Yes, my non-working (with regard to DNS on a NAT VM) host has dnsmasq running on it.  But only on the localhost/loopback adapter.  Up until Big Sur, this wasn't a problem.  VMware Fusion took care of its own network stuff for the most part, so it is agnostic to any host-level thing already bound to port 53.  It bound its own DNS server to its own NAT adapter, and everybody was happy.

Now, starting with Big Sur, VMware Fusion leverages more OS-level networking stuff.  So to implement a DNS server on its NAT adapter, it asks the host OS to start a DNS server.  The problem here is that mDNSResponder is greedily attempting to bind port 53 on every address.  And in my case, because I have something using port 53 on loopback, mDNSResponder fails to bind port 53 on any address.

If I stop the dnsmasq service (in my case via sudo launchctl unload /Library/LaunchDaemons/org.macports.dnsmasq.plist), everything works perfectly.  Any VM using NAT now has the ability to look up domain names using the DNS server provided by DHCP.

Suggestion for a VMware-level fix (i.e. in an upcoming version of VMware Fusion):

  • When using mDNSResponder to implement a NAT-level DNS server, attempt to bind only to the adapter/address that is being used by VMware for NAT (assuming this is possible).  This would ensure that there will be no conflicts with whatever way the host OS is configured to do networking.

Suggestions for a User-level fix (i.e. for us mortals before a fix can be released), either:

  • Before launching VMware Fusion, be sure that nothing is binding port 53 on any address.
    After a VM has been started, you can probably re-start whatever was using port 53 again. At least I can in my case where dnsmasq was bound to 127.0.0.1:53
    Though note that starting any new VM after you've re-occupied port 53 will break DNS for every running VM at this point.
  • Configure every VM guest to use a not-on-host DNS server.  (e.g. 1.1.1.1 or 8.8.8.8)

 

View solution in original post

Contributor
Contributor

Yep.  Same issue here.  Took a little digging but I found that the OpenDNS Roaming Client binds to 127.0.0.1:53 and prevents DNS (from DHCP)  in the VMs from working.  Quick fix was to set DNS in the VMs to use public DNS servers instead.

Hopefully vmware figures out a way to resolve.  In fact, I'd say if somehting is already listening to 127.0.0.1:53, use that instead of launching their own mechanism.

 

0 Kudos
Contributor
Contributor

Just wanna chime in here.

 

I'm experiencing issues with regards to using Internet Sharing (NAT) ever since upgrading to Big Sur.

Mac (host)

Fusion 12

(Internet Sharing NAT)

Cisco AnyConnect VPN > VM

 

Does NOT work at all. Very frustrating. 

0 Kudos
Enthusiast
Enthusiast

If your host has a VPN connection, there is a workaround available here:
https://communities.vmware.com/t5/VMware-Fusion-Discussions/Share-host-VPN-with-guest/m-p/2810095/hi...

If your host has anything listening on port 53 (DNS) before starting a VM, the workaround is prior in this very thread:
https://communities.vmware.com/t5/VMware-Fusion-Discussions/DNS-Forwarder-Does-Not-Seem-to-Exist-in-...

Between never considering the case where the host OS has something listening on port 53 on any interface, and never considering the case where the host OS has a VPN connection, I'll say that VMware has sort of dropped the ball with being Big-Sur-ready.

0 Kudos
Enthusiast
Enthusiast

I've recently tested Parallels (in a Big Sur VMware Fusion VM... go figure!), and I've found something interesting:

It has been suggested that Big Sur doesn't allow kernel extensions, and that's why VMware Fusion goes down a different (and problematic) method for providing network connectivity to a VM.  But I see no evidence that this is actually true.

In the Big Sur machine that has parallels installed:

test@tests-Mac ~ % sudo lsof -i -P -n | grep :53
mDNSRespo 154 _mdnsresponder 6u IPv4 0x15f6d16a49955957 0t0 UDP *:5353
mDNSRespo 154 _mdnsresponder 7u IPv6 0x15f6d16a4995737f 0t0 UDP *:5353
test@tests-Mac ~ %

I conclude from this that Parallels isn't needing to bind to a real host-level network interface binding on port 53 to provide DNS capabilities.  And as such, Parallels won't have the requirement that nothing is listening on port 53 for NAT interface DNS to work!

How is this possible?  Let's look at kernel modules:

test@tests-Mac ~ % kextstat | grep -i parallels
Executing: /usr/bin/kmutil showloaded
No variant specified, falling back to release
142 1 0xffffff7fa156e000 0x16000 0x16000 com.parallels.kext.hypervisor (16.1.1 49141) 9C31EA79-2CB3-3647-B215-726F634ABB6B <8 6 5 3 1>
143 1 0xffffff7fa15a1000 0x2000 0x2000 com.parallels.kext.vnic (16.1.1 49141) 6975F280-4A74-3257-A0FA-80570EA8041E <6 5 3 1>
144 0 0xffffff7fa158c000 0xc000 0xc000 com.parallels.kext.netbridge (16.1.1 49141) 236F5FD8-91A0-3A01-B7CE-D415FF77EC50 <143 142 6 5 3 1>
145 0 0xffffff7fa159a000 0x5000 0x5000 com.parallels.kext.usbconnect (16.1.1 49141) D4CE3CF1-5622-3679-B66B-CFD76C2A3681 <60 8 6 5 3 1>
test@tests-Mac ~ %

That's right.  Parallels on Big Sur has loaded kernel modules, and as a result VMs are able to seamlessly use the network, regardless of presence of a VPN on the host, or anything listening on port 53.

@nancyz Did VMware perhaps misinterpret the timeframe of Apple's threat to take away kernel modules?  Or is VMware just planning for this future sooner than Parallels?  (And as such, the VMware product for Big Sur currently has many more growing pains than the Parallels product).

0 Kudos
Contributor
Contributor

I see this on port 53 - 

dnscrypt- 1080          nobody   45u  IPv4 0x6c2cdd23f999c089     0t0    UDP 127.0.0.1:53

dnscrypt- 1080          nobody   46u  IPv4 0x6c2cdd2407147c91    0t0    TCP 127.0.0.1:53 (LISTEN)

dnscrypt- 1080          nobody   69u  IPv4 0x6c2cdd23ff176ad9      0t0    TCP 127.0.0.1:62722->127.0.0.1:49269 (ESTABLISHED)

I don't now if this is a service I should stop but what's even more worrisome is the 'nobody' as the user. Configuring a DSN once VMWare and Windows 10 is up does nothing to fix the NAT issue. 

0 Kudos
Enthusiast
Enthusiast

@JavierIBM The info you pasted shows that your host is already binding port 53, which means that VMware on Big Sur will not be able to provide DNS services to VMs using a NAT network connection.

At some point did you manually install something called "DNSCrypt"?   How you installed it (e.g. via Homebrew) would affect how you could temporarily unload/disable it for testing purposes.

0 Kudos
Champion
Champion

There are ways to force load kext's in big sur, but it's not recommended by apple.  VMWare did the right thing by following the standards, but you're right, there's growing pains.

0 Kudos
Enthusiast
Enthusiast

kexts load the same way in Big Sur as they do in Catalina.  I get the impression that VMware interpreted Apple's use of "deprecated" as meaning "not allowed".   Perhaps ironically, the Parallels strategy of "change nothing" puts them in a state where it works just fine on Big Sur.  They still use kexts, so Big Sur networking works exactly the same as it did with Catalina and prior.

0 Kudos