VMware Workstation VMs Web Traffic Being Blocked

johnpoz

@dfinjr I could move it to bridged network.. It just defaults to natting, one sec

stephenw10

Still not convinced we are not chasing the wrong thing here. Unless someone can show me an oversized packet for a connection that's actually failing?

How are those other private subnet connected @dfinjr ? What's routing them?

Steve

DaddyGo

@johnpoz said in VMware Workstation VMs Web Traffic Being Blocked:

I don't see any hostd directory there in my shiny new vmwareworkstation pro install.

hidden "folders" in principle...

DaddyGo

@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:

.......................

please draw us (even by hand) a network topology (if this is not a problem)

dfinjr

@stephenw10
Routing is happening in a few places. Routing is primarily being through pfsense/netgate. Here is a quick diagram:

johnpoz

@daddygo I am viewing hidden folders.. I don't see any of those folders under there

And here in bridge mode, still the current mtu

DaddyGo

@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:

Routing is happening in a few places.

you are a mind reader, hee hee hee

dfinjr

@daddygo
Here is a little more:

DaddyGo

@johnpoz said in VMware Workstation VMs Web Traffic Being Blocked:

I am viewing hidden folders..

since log(s), may be generated here later, try to turn off - turn on guest OS
(yours is a fresh install)

DaddyGo

@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:

Here is a little more:

what type is this TP-Link switch?

johnpoz

@daddygo I wonder if that has something to do with shared VM?

https://communities.vmware.com/t5/VMware-Workstation-Pro/Shared-VM-gone-in-workstation-16/td-p/2303228

After installing version 16, I realized that the Shared-VM feature was removed and there is no "hostd" service on Linux but in windows "hostd" exist but there is not any section for configuration in GUI or CLI!

Looks like it maybe went away, and then came back in 16.1 - but maybe gone again in 16.2?

https://docs.vmware.com/en/VMware-Workstation-Pro/16.2.0/rn/VMware-Workstation-1620-Pro-Release-Notes.html
The shared virtual machine feature is no longer supported from Workstation 16.2.0 Pro.

DaddyGo

@johnpoz said in VMware Workstation VMs Web Traffic Being Blocked:

I realized that the Shared-VM feature was removed and there is no "hostd" service on Linux but in windows "hostd" exist but there is not any section for configuration in GUI or CLI!

I started with 16.0 and upgraded to 16.2.2 (step by step), but never ran windows here, only Ubuntu Focal desktop installed..

(I only use it for daily work, Ubuntu on one monitor and Win10 on the other)

johnpoz

@dfinjr Where exactly are you sniffing.. Sniff your traffic on that .202 workstation, on the interface that you have bridged your VM with.. I take it there is only 1?

Look and see what is being put on the wire.. If its not your standard 1500 (1514) sized frame, then yeah your going to have problems.

Your saying that VMs on this .203 host are not having problems - sniff there what are the frame sizes?

dfinjr

@daddygo
The tp-link is a L2 switch model: TL-SG108.

@johnpoz
Those earlier uploads with the word "client" are all from .202, the additional capture is from pfsense. Yep, the .202 client captures are from the bridged "ethernet" adapter. Only connected interface on the system outside of "loopback"

So let me clarify there. .201 is the hosting system (no browing issues) and .202 - .204 are all VMS having the browsing issues.

How is your lab test going?

dfinjr

@stephenw10
Happy to execute any ideas that you have as well. Please don't hesitate to ask.

stephenw10

Mmm, I think this is not what it appears at all. I suggest the NIC driver is doing something that simply makes it appear to be large frames in the virtual network.

Looking at the simultaneous pcaps from earlier (were they actually simultaneous?) it appears what's happening here is the 'Server Hello' packet from an external server never makes it to the client.
If this is an MTU issue it appears to be the other way, large packets are not passed into VMWare.

Steve

stephenw10

Looks like the pfSense side was only set to 100 packets so it's hard to know for sure we are seeing the same thing. Also it wasn't filtered by an external IP.

Can we see simultaneous pcaps from the pfSense client and LAN filtered by the external you try to connect to. At least 1000 packets on each. Though if it's filtered you should not need that many.

Steve

dfinjr

@stephenw10
That is interesting about the packet size being virtual side only.

Yep they're as simultaneous and I can think to make them. The capture from pfsense will be longer as I do these steps: Pfsense > Packet capture > set interface to labsystems (vlan 2000 - 172.16.0.0/24) > host 172.16.0.202 > port 443 > start capture > jump to vm > start Wireshark listing for tcp 443 > bring up chrome and browse to the sites that aren't playing ball > let capture run for about 8-10 seconds > stop > save as with compression > stop capture of pfsense > upload both to this forum.

I'd be happy to run another capture. I have a 2mb hard upload limit on this site so I was intentionally trying to keep these small. I'd be happy to upload a bigger packet capture just let me know where.

Can you frame out for me exactly how you want me to kick off the capture, how long and with doing what? Just want to make sure I get it to the exact criteria that you need to see.

stephenw10

Yeah, that's absolutely what's happening here. Look at the second pair of captures. Filter by ip.addr == 151.101.2.219.
That IP sends the Server Hello in 4 TCP segments but the client only receives the last part, smallest packet.
Connection fails.

dfinjr

@stephenw10
So are you thinking that comms are getting out from the client out to the hosting internet server, the hello traverses back and then the larger packets aren't surviving? What do you think could cause that?