VMware Workstation VMs Web Traffic Being Blocked
-
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
DHCP now, same results
To recap a bit, on anything that is VM related guest Linux/Windows this MTU sees, please do it a packet capture on an external physical machine
I ask, clean version of the WS16?
(only two can hear - :))+++++edit:
what network card is in the machine running WS16?+++edit2:
VMware HCL approved? -
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
Attached is the capture log from Cisco being the backbone for the same VMs
That was actually taken on the Cisco?
Yeah there are oversized frames there but all between 172.16.0.202 and 172.17.0.7. What are those things? I had assumed they are both inside VMWare. And also that 192.168.1.100 is?
Steve
-
Ok I'm going to try and tag you all because I know you're all waiting on me at this point :)...
@johnpoz
I'm looking to see if there is something that I can configure in the virtual switch itself tied to VMware Workstation 16 Pro. I don't see specifics yet tied to MTU but so far just seeing some basic items such as host-only/NAT... items of the sort. I'm the only one using this environment for lab/demonstration purposes. If there was a jumbo frame it would of likely been me but most everything outside of standard static networking is pretty vanilla. Stock installs/stock configs. I don't know enough to get fancy.@DaddyGo
I believe it is a clean install of WS16? What would make it not clean? :)
Here is the card on the hosting system:
@stephenw10
That packet capture was taken from the same 172.16.0.202 client but the network backbone being the Cisco ASA. Sorry I was very unclear with how I said that earlier.Those are likely packets for the management software I was talking about. I am a sales engineer for HCL BigFix. The frames you're seeing are likely my other subnet managed systems reaching back out to the 172.16.0.202 as it is my hosting server for BigFix. Not both inside of VMware, the only hosts inside of vmware are the 172.16.0.0/24 subnet, anything outside is physical systems as what would be happening from 172.17.0.0/24. Not sure on 192.168.1.100 at the moment I'll have to look into that. I have pfsense running on its default subnet of 192.168.1.0/24 so perhaps another systems is sitting there somewhere on that same subnet.
To everyone: Why would the Cisco equipment flow this traffic no problem vs what is happening with PFSENSE? I am not trying to bash pfsense or anything I really want to use it. I am just saying what is the difference in the handling?
Thanks!
-
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
so perhaps another systems is sitting there somewhere on that same subnet.
You shouldn't see any packets... I see specific traffic from sent from 172.16.0.202 being sent to 192.168.1.100 in one of your sniffs. With a large frame size!
Why would the Cisco equipment flow this traffic no problem vs what is happening with PFSENSE
Maybe the interfaces on the cisco is set to allow jumbo.. Doesn't matter to be honest - putting frames on the wire at that size is BORKED!! They are not standard jumbo size, they are not any other size like baby giants, etc.. They seem to be just someone pulled out of then air and lets use 1753 as a mtu? The cisco sure didn't pass that traffic out to the internet with that frame size that is for sure..
Trying to run a network with that odd ball frame size is going to cause you nothing but grief and issues..
In the process of installing vmworkstation 16.2.2... This is the nic it created on my windows machine. You can see its not using jumbo and defaults to 1514.. What does your show?
-
@johnpoz
So I just figured it out, that .100 is a google wifi device feeding a handful of other clients. I didn't build that vlan on this build of the pfsense during my troubleshooting.I can go back to the Cisco device and see if it is configured to do that if you'd like. I don't believe I configured anything special on that device in terms of that either as I didn't really get into anything to do with Jumbo Packets before this conversation. Whatever is taking place now with PFSENSE that you're all seeing was taking place on the Cisco ASA. I am happy to provide whatever proof you all would like.
@stephenw10 172.17.0.0/24 doesn't exist on PFSENSE however if you saw that packet capture from the Cisco ASA version that would be feeding the same google wifi. PFSENSE: google wifi is sitting at 192.168.1.100 vs Cisco at 172.17.0.7. I do have clients I am managing on the google wifi.
@johnpoz said in VMware Workstation VMs Web Traffic Being Blocked:
The cisco sure didn't pass that traffic out to the internet with that frame size that is for sure..
Not sure what to tell you there :) What test would be handy for me to prove to you that it was happening? (not trying to be combative in anyway so please don't read that on that context but I believe I can prove it; this coming from the rather naive position that the traffic happens on Cisco so far no issue). Again my goal here is to retire and move to pfsense and I'm trying to make that feasible otherwise I wouldn't be spending time trying to fix it. I have only owned the hardware for 8 days counting today.
-
-
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
handy for me to prove to you that it was happening?
Your isp connection sure didn't have a mtu size of 1753, so a routing device would/could fragment it down to correct mtu size the network its routing the packets over.
Here i just setup ws16.2.2, out of the box setup.. Installed a VM (ubuntu)... Browsing amazon via nat interface.. the vm has a 192.168.37 IP from WS
Sniffing - at my pfsense router, on the physical network... You can see all 1500 (1514) frames.. They are coming from my VM host IP 192.168.9.100, because the VM is using the natting workstation network.
You are going to have NOTHING but issues trying to use a frame size of some odd size like that.. Once go through a layer 3 router, the frame could be adjusted to the frame size on the transit network to get to the next hop, etc.. But even if that works, its problematic doing that! Now your router is spending all the time fragmenting up packets that are some odd ball size to the standard size.
I do not know where it is happening (but sure isn't pfsense), but a 1753 (1767) frame size not standard for any ethernet network.
-
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
Here is what I see:
NO!! that is the not the interface - that is your VM interface... What is the interface on the HOST os that vm workstation created!
See the different net1 net8 and then the natting interface.
-
Just to be sure we are not chasing the wrong thing here; is that traffic between local subnets also failing?
Is that routed though pfSense?
Do we see any oversized frames on connections between the internal VM and external hosts? I would definitely expect that to fail but I didn't see any when I looked initially.
Steve
-
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
I know you're all waiting on me at this point :)...
do you see something strange here?
C:\ProgramData\VMware\hostd\hostd-n.log
vswitch section...
Cats bury it so they can't see it!
(You know what I mean if you have a cat) -
@johnpoz said in VMware Workstation VMs Web Traffic Being Blocked:
Browsing amazon via nat interface.. the vm has a 192.168.37 IP from WS
Hi @johnpoz
Nat will work, bridged will not.I believe you on the MTU thing :) I just am having trouble wrapping my head around this all but I'm working on that understanding.
I am still trying to figure out how those Jumbo Packets are originating. Is it possible that this was happening with Cisco and then getting fragmented and handled by the Cisco appliance?
I see only two virtual adapters but this is what I see:
No nat interface for me:
@stephenw10
No traffic is failing between internal subnet is good and traffic from that subnet (172.16.0.0/24) to the google wifi looks good. Some slight complications with the DMZ subnet I created but that is on the back burner at the moment.@DaddyGo
Don't see that log: (would you like to see another log?)
-
@daddygo what are you running exactly - I don't see that in my brand new install of vmware workstation 16.2.2 on windows 10.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.03 | Lab VMs 2.7.2, 24.03 -
@daddygo
Think I found it:
-
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
Don't see that log: (would you like to see another log?)
C:\ProgramData\VMware\hostd\hostd-n.log
the "n" is just the current log version, which in your case is now 64 the rest is already compressed by the log rotator
Cats bury it so they can't see it!
(You know what I mean if you have a cat) -
Also on win10.
The only difference I saw between our two configurations was that you were running NAT based vs bridged:
-
@daddygo I don't see any hostd directory there in my shiny new vmwareworkstation pro install.
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.03 | Lab VMs 2.7.2, 24.03 -
@johnpoz said in VMware Workstation VMs Web Traffic Being Blocked:
what are you running exactly
same....
-
@dfinjr I could move it to bridged network.. It just defaults to natting, one sec
-
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
-
@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...
Cats bury it so they can't see it!
(You know what I mean if you have a cat)
