VMware Workstation VMs Web Traffic Being Blocked
-
@daddygo
Thank you that got me to the config file.Powered off the host and modified the file:
Made the modifications and started the machine again.
Unsurprisingly it needed me to set the info again for the static IP (Not a DHCP subnet) and is now showing up like this:
However I am sad to say it is the same result.
Same sites don't load same sites do. Captured a fresh packet capture with the new vmxnet3 device just in case it would be handy.clientcapture443-4.pcapng.gz
-
@daddygo
I'll do you one better. Spun up a Ubuntu instance.Same results:
Netgate.com loads but none of the other sites in question.
Open to any and all thoughts :)
-
@dfinjr and you still have same issue in that pcap
That is going to have nothing but problems on a normal 1500 mtu ethernet network..
Forget about what loads or doesn't load - putting that sized frame on a etherenet network that is not designed for that size is going to have nothing but problems.
Even if you have something that fragments it back down to the standard, that is not a fix.. The fix is to use standard frame size.
Where exactly are you sniffing that - inside the virtual machine, on the vm host to the wire? That is going to be nothing but problematic no matter if sniffing on the vm, or the physical nic..
-
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
However I am sad to say it is the same result.
OMG.... this is get more interesting
but I still say it's not pfSense that's doing thistotally agree with John, but what makes this MTU value?
Cats bury it so they can't see it!
(You know what I mean if you have a cat) -
Mmm, isn't that internal traffic to VMWare though? Is that actually failing?
It looked like it was using standard sized frames for external connections previously. Though this absolutely does feel like an MTU issue.
Steve
-
@daddygo said in VMware Workstation VMs Web Traffic Being Blocked:
but I still say it's not pfSense that's doing this
pfsense has ZERO to do with this that is for sure!! Pfsense has nothing to do with some client on the network putting odd ball sized frames on the wire.
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.11 | Lab VMs 2.7.2, 24.11 -
To everyone here. I do have a Cisco packet capture from earlier this morning. Would that be neat to see? Traffic flows... No modification to VM at all.
-
@johnpoz said in VMware Workstation VMs Web Traffic Being Blocked:
pfsense has ZERO to do with this that is for sure!!
Yup, but the OP came here because he thought it was a pfSense thing
the son of man is always learning, hihihi
(this would be interesting to solve, it's probably just a banal problem)Cats bury it so they can't see it!
(You know what I mean if you have a cat) -
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
To everyone here.
I would go further by saying that the NAT solved the problem yesterday, here's where the dog will be buried
-
@daddygo said in VMware Workstation VMs Web Traffic Being Blocked:
OP came here because he thought it was a pfSense thing
They always do - xyz doesn't work, must be pfsense ;) But a packet capture showing some odd ball frame size on some client being put on the wire sure has nothing to do with pfsense.
What version of vmware station is being used here? I find it hard to believe such an odd ball setup is default.. Someone prob tried setting jumbo frames at some point or time, and maybe their cisco was set for those which is why it so called worked..
1753 sure isn't even a normal jumbo size, or standard anything..
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.11 | Lab VMs 2.7.2, 24.11 -
@johnpoz
Don't burn me at the stake already guys. Attached is the capture log from Cisco being the backbone for the same VMs. Traffic goes. Why would that be the case? Again please educate me :) -
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
Don't burn me at the stake already guys.
Don't take it to heart, we're just "moaning" a bit...
can we look at the case where you give DNS (Unbound) and DHCP to the VM out of the pfSense box?
- say from a single interface without VLAN(s)
(forget about pi, for a bit)
- say from a single interface without VLAN(s)
-
@dfinjr that is still all messed up! your seeing same frame sizes over the standard with a max of that 1753
-
@johnpoz said in VMware Workstation VMs Web Traffic Being Blocked:
What version of vmware station is being used here?
in principle VMware WS16PRO
-
DHCP now, same results
-
@dfinjr your actual vm has mtu set to 1500, so somewhere in the vmworksation switch or setting you have it borked up..
Someone at some time tried doing something with jumbo frames is my guess.. But that frame size isn't even a standard for jumbo or even baby giant frames which could be 1600.
-
@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?
