VMware Workstation VMs Web Traffic Being Blocked
-
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
Test with speedtest.net: (timed out 1472)
Well you got something wrong with your isp or the path from your isp to them... Works just fine here
What about loading www.speedtest.net - with packet capture so we can see what your syn and the answer syn,ack has in them.
-
Sure would be happy to... Without MSS I am guessing?
-
@dfinjr example
-
@johnpoz
With MSS on:
MSS=1394With MSS off:
MSS=1430 -
@dfinjr where did you sniff that.. What are you looking at exactly for when you see 1430?
Which packet.. Where exactly did you set MSS - what interface?
How could the SYN that has not yet entered pfsense be changed?
Need to see the SYN that you send, and what the syn,ack says in response.
If I change the MSS on pfsense lan, to 1400, and do a sniff on lan, I still see 1460, if sniff on wan.. see 1360 (which is 40 minus what I set of 1400)
-
That looks like exactly like what he's seeing. The SYN goes out at 1460. The SYN-ACK comes back at 1430 or 1394 depening if MSS is set or not.
Really the only question I have here is why this is necessary. I expect path MTU to discover that if there really is a restriction somewhere.
Steve
-
@stephenw10 said in VMware Workstation VMs Web Traffic Being Blocked:
The SYN goes out at 1460
Where are you seeing that?
Oh I see it now in the info section.
-
Mmm, yeah if you look at the latest pcap and then look at, for example,
tcp.stream eq 11.
You can see the syn-ack comes back with mss 1430 but it still fails. Whatever packets it's sending are not passed through VMWare. -
Hi there.
I did that sniff at 172.16.0.202. What I was looking for was the matching public IP address right at the beginning of the TCP conversation between me and speedtest.net. Pretty much client hello then looked for the [SYN, ACK] to see the options for that digging out that MSS. At that point though the server has already responded. I think I found what you are after though under the [SYN, ECN, CWR] where the client is outlining the MSS: (tell me if I am wrong)
I just went through the capture from the no MSS setting and I don't even see that packet originating like what I saw in the screen shot directly above...
On the PFSENSE I honestly have set all my interfaces with the MSS setting at 1434 because then everything started playing ball again. So this would be existing on all interfaces.
Am I missing it or is the capture with MSS on not coming up with that packet as what I showed in the screen shot above from when MSS is enabled?
@stephenw10
I have no idea why it is necessary... that's why I am still here to try and figure it out :)On you last commend I am kind of hanging on that. I am not modifying anything within the VMWare configuration at all, only MSS on the PFsense... But how is that possible? If the packets weren't getting out of VMWare then the changes in firewall wouldn't matter right? So why do they?
I obviously can't make sense of this yet...
-
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
If the packets weren't getting out of VMWare then the changes in firewall wouldn't matter right? So why do they?
They do get out. But when they come back the large packets are not passed back to the VM by VMWare. The pcaps you ran on the host showed the reply packets arriving there but pcaps on the VM itself did not show them.
I'm assuming that last pcap was on the VM?For example. Look at this tcp stream from packetcapture-5:
I wish I knew some better way to show that on the forum. Suggestions welcome!
The client send mss 1460. The server responds 1430.
But when the server uses 1430 (1484 total packet size) the client never sees it. It just sends a duplicate ACK. -
@stephenw10
Oh I see. Yep PCAP was on the VM (172.16.0.202).Yep I don't get it. I see what you're saying and all just can't wrap my head around what is going on here.
-
This post is deleted!
