VMware Communities
wohler
Contributor
Contributor
Jump to solution

Bridged networking flaky in VMware 12/Big Sur

I recently upgraded to Big Sur and found I had to upgrade Fusion to version 12 as well. I have a Debian Linux client.

Ever since then, my bridged network has been behaving strangely. Viewing Google pages in the browser seems to work, but every other page comes up blank. fetchmail can't connect to my mail server. My NAS can start an rsync backup to my client, but it always eventually dies with:

Connection to 192.168.50.4 closed by remote host.
rsync: connection unexpectedly closed (653017239 bytes received so far) [receiver]
rsync error: error in rsync protocol data stream (code 12) at io.c(605) [receiver=3.0.9]
rsync: connection unexpectedly closed (58 bytes received so far) [generator]
rsync error: unexplained error (code 255) at io.c(605) [generator=3.0.9]

My NAT adapter is working as it always has.

Am I waiting for a Big Sur or Player 12 update that will magically fix bridged networking, or is there some tweaking that is required to fix this?

 

Labels (3)
0 Kudos
2 Solutions

Accepted Solutions
gringley
Hot Shot
Hot Shot
Jump to solution

...well 

sudo ip link set dev ens160 mtu 1499

then allowed my Ubuntu 20.04 to apt where everything was corrupt at the default 1500...

View solution in original post

gringley
Hot Shot
Hot Shot
Jump to solution

You know what...I am on Monterey 12.0.1 and I cannot reproduce this problem anymore.  Perhaps Apple figured something out?

View solution in original post

0 Kudos
11 Replies
Djelibeybi
Contributor
Contributor
Jump to solution

You're not the only one. Something is blocking inbound connections from the host to any guest on a bridged network after some amount of time. If you initiate the connection from the guest, it all starts up again. I've taken to running "ping <gateway>" from inside my guest(s) which seems to keep the network up for inbound connections.

0 Kudos
Djelibeybi
Contributor
Contributor
Jump to solution

I may have stumbled upon a solution: switching from the vmxmet3 paravirtual device to the e1000e emulated device. You can't do this in the UI, so you need to edit the vmx file and change ethernet0.virtualDev to "e1000e"

0 Kudos
wohler
Contributor
Contributor
Jump to solution

Thanks, mate. Even though your symptoms were a little different, it was worth a shot. My virtualDev setting was already e1000. I tried e1000e and vmxnet3 and experienced the same symptoms. I left it at e1000e though.

0 Kudos
Djelibeybi
Contributor
Contributor
Jump to solution

Worth a shot. What's really weirding me out is that it doesn't appear to be kernel specific. I have two Oracle Linux VMs (OL7 and OL8) which are both running the same kernel version (5.4.17) but the network only drops out for the OL8 guest if it's set to vmxnet3. The OL7 one doesn't exhibit the problem. 

0 Kudos
d0wntime
Contributor
Contributor
Jump to solution

Bump!  This problem still exists, and affects VMs of all operating systems types.  It affects both a Windows Server VM of mine, and an OpenBSD VM.  I need bridged networking to work ... anybody figure out anything here?

0 Kudos
gringley
Hot Shot
Hot Shot
Jump to solution

Another thread got what I think is the right answer finally - MTU.  Apple appears to be adding tags or something.  An MTU of 1472 fixed my Linux and I am testing now to see how high I can go towards 1500.

gringley
Hot Shot
Hot Shot
Jump to solution

...well 

sudo ip link set dev ens160 mtu 1499

then allowed my Ubuntu 20.04 to apt where everything was corrupt at the default 1500...

d0wntime
Contributor
Contributor
Jump to solution

Right after I posted, I found the other thread.  Thanks, y'all!

0 Kudos
wohler
Contributor
Contributor
Jump to solution

@gringley, thank you so much for posting here!

It's like back to the future. I haven't had to mess with the MTU since the 80s and thought it was a solved problem. The number that worked for me on my Debian Bullseye system was 1491.

$ sudo ip link set eth0 mtu 1491    

I also updated the network settings in the GUI so the interface would be initialized properly (GNOME 3 menu in upper right > Wired Connection > Wired Settings > Interface Gear Icon > Identity > MTU).

Thanks again. I've already joyfully thrown out all of my inadequate workarounds.

0 Kudos
gringley
Hot Shot
Hot Shot
Jump to solution

You know what...I am on Monterey 12.0.1 and I cannot reproduce this problem anymore.  Perhaps Apple figured something out?

0 Kudos
wohler
Contributor
Contributor
Jump to solution

Yes, the same for me. I got my nine bytes back, and that was with the existing version of Fusion (12.1.2). Upon starting Fusion, I was welcomed to a screen saying that Fusion version 12.2.0 was available that "supported Monterey". It provided a hardware version upgrade to version 19.

Thus, another solution to this problem is to install Monterey.

Thanks again, gringley!

0 Kudos