Good morning to everybody,
I have this big problem with Fusion and Big Sur. The scenario is the following.
Host Machine:
VMware Fusion 12.1.0
MacOS Big Sur 11.0.1
Network relevant details:
en0 -> untagged interface adapter on a private network
vlan0 -> tagged interface adapter on a public network
Guest Machine
OS: Ubuntu 20.04.1
Network: public ip on a network adapter bridged on vlan0
The problem is that the guest is unable to ping outside the host (guest <-> host is ok).
In other words, the default gateway for the vlan0 doesn’t respond to the guest (in any case both firewalls are off and forwarding is enabled).
I also used tcpdump and I have verified that packets go out from guest and reach the host, but they do not come back.
I already tried many of your dns or nat tested solutions to the related issues, but the problem persists.
What is interesting is if I move the guest bridge on the en0 (of the host), reconfiguring it with a public ip, all works (as expected).
This for saying that the problem should be strictly related to VLAN.
Note: before updating (both to Fusion 12 and Big Sur) all was working between host and guest (both having a public IP address) and routing to Internet.
Any help or suggestions is very appreciated.
Thank you.
Cheers,
—Carlo
Thank you for your reply. Tagged VLAN could not be used on MacOS 11.3, Fusion 12.1.1. I will try again on MacOS 11.3.1.
I'm on Big Sur 11.3.1 and VMWare Fusion 12.1.2 and I can't still use the Vlans defined in the host network config, inside any guest VM. From the host I can use them just fine, but not inside (Not even network connection established). Did you have to do something special to make them work?
Thank you in advance.
Not at all. My previous configuration comes back to work just after the last BigSur update. Probably you have some mistakes elsewhere not depending by BigSur.
On the Host I have created the VLAN connection:
It correctly gets an IP and I can use it just fine from the host to confirm it works:
curl google.com --interface vlan4
Then in the Guest VM config I simply choose the interface:
But then the guest (I've tried in both Windows and Linux VMs) doesn't even get an IP. If I manually define the IP in the same subnet as the Vlan, I can at least ping the host and the other way around, but nothing else.
Am I missing something?
could be the dns server not correctly routed?
To avoid other mistakes, you also can try to use static private address without vlan, so as to double checking your conf.
In macOS 10.15.7 (Catalina), Fusion 12.1.2, the tagged VALN is set as follows and it works.
But the tagged VALN did not work with the same settings on macOS 11.4 (Big Sur) and Fusion 12.1.2.
Both adds01 and wins02 are Windows Server 2019 virtual machines.
I can ping between adds01 and wins02, but neither can ping the default gateway.
Internet communication is also not possible. In the case of Catalina, ping goes through the default gateway, Internet communication is also possible, so there is no mistake in network settings.
Is there a way to deal with it?
It is not easy to debug cause I suppose the mistake is outside vmware.
In fact, from what I see, the VLAN 140 is not available to vmware (red).
Moreover, the dns server of the first host is set to localhost.
--Carlo
I have this very same problem with Fusion 12.1.2 and MacOS Big Sur 11.4. Only difference is my machine was Catalina before.
Windows 10 VM and "Share with my mac" network interface works fine, gets IP, can ping out to internet.
Kali-rolling VM and VLAN interface gets nothing. No DHCP response. tcpdump on the VM shows:
19:33:28.112328 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:50:56:33:db:e0, length 285
19:33:28.152712 IP0 (invalid)
19:33:28.152717 IP0 (invalid)
19:33:28.152718 IP0 (invalid)
19:33:28.152718 IP0 (invalid)
tcpdump on the gateway shows:
19:33:28.342196 IP 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:50:56:33:db:e0, length 285
19:33:28.380607 IP 172.16.69.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
19:33:28.380652 IP 172.16.69.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
19:33:28.380667 IP 172.16.69.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
19:33:28.380678 IP 172.16.69.1.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
It's almost as if the interface isn't de-tagging the VLAN, but it used to before... again, literally the only change here is Catalina -> Big Sur
Help us, vmware, you're our only hope!
From my side at this point I can suggest to open a case incident to Apple.
2013 MacPro
BigSur 11.4
VMWare Fusion 12.1.2
Bonded interface with VLAN tagged sub-interfaces.
Guest OSes Network Adapaters attached to vlan-tagged.
Same behavior - ARP seems to work, unicast IP doesn't.
I have a new Mac Pro that was running Catalina and was upgraded to Big Sur this evening. I also installed the latest Fusion 12 tonight. My en0 port is my management interface. My en1 is for Fusion VM traffic. The en0 interface is on an access port and working just fine. My en1 interface is on a trunk port. If I create a VLAN interface on en1, I can see the host pick up an IP from the dhcp server on that VLAN. Not really what I want, but I can spare it. If I map a guest VM to that virtual VLAN interface I get nothing but an APIPA address. If I manually IP the guest it can ping the host, but not the gateway. This did not work on Catalina before the update and it certainly isn’t working after the Big Sur update.
Is there documentation on how to setup trunking of VLANs in Fusion? Should I be bridging an interface somewhere?
Problem persists under Big Sur 11.5.1.
I thought I would bypass the problem for now by putting en1 on an access port for the VLAN I needed. That did not work at all. Host is still picking up an IP from the VLAN DHCP, but still getting APIPA on all the hosts that I map their ethernet to en1.
This is exceptionally lame.
Have double checked the trunk is correctly configured? And that the response is coming back with a dotQ tag so the switch knows where to send it? I would maybe use wire shark at every end node to see exactly what is coming across and sent onto the wire. Then you would see what is being tagged and also who and what is going on with dhcp.
Some Wiresharking is certainly in order. I would assume the tagging is working since the host is getting an IP from that VLAN and I cant see how that would work otherwise.
Manjiri did just that in this thread:
I believe the host in this case would be the other side of the trunk and would be auto setup as a trunk. Have you tried setting a native trunk port for Untagged traffic across a trunk? Also you may have done this already but in Linux you can go to /etc/network config file and set what interface gets what ip from where. all things I’m sore you know to do just throwing it out there. One last thing you may want to try traceroute and tracert to see exactly where the frame is being dropped.
Just upgraded to 11.5.2 and things seem slightly better. I can actually get a ping packet out of the main physical interface onto the network. Getting it to come back in and then into the virtual machine is still not working.
Anyone else have any better luck?
(I am using bonded LACP interface pair on MacPro as the base physical interface)
Problem still persists in Big Sur 11.6
I’ve found a workaround which suits my needs though.
Instead of creating a VLAN interface in macOS and using that to bridge the guest VM, I pass through the regular Ethernet interface and then in the guest VM, add a VLAN interface (eg en33.5 for VLAN 5) and disable ipv4/6 on the original interface (eg, turn off ipv4/6 on en33). This works with Linux VMs. Haven’t tried macos or windows Guests.
I'm on VMWare Fusion 12.2.0 and Big Sur 11.6.1 and I'm still have problems with this, even using the workaround posted above.
The last thing I've tried was to just create the VLANs inside a Linux VM (VyOS), and it kinda works, but for some of them I correctly receive the responses, but for others it just timeouts. This only happens inside the VM, because when using the same VLANs directly from the host everything is fine, so the problem seems to rely on the bridge between the host and the guest when using VLANs.