VMware Workstation VMs Web Traffic Being Blocked
-
It only somewhat helped. Afterward I could get speedtest.net to render.
-
@dfinjr and if you ssh to your pfsense and do a ifconfig - what are all the mtu for all the intefaces showing?
Looking at your ciscoasa pcap - the frame sizes are sill OFF.. 1434 and 1380?
-
@johnpoz
doesn't look like this output shows the MTU:
is there another command I can run in order to give you what you're after?
Yeah I bet the frame sizes were still off. No idea how the ASA was compensating for it.
-
@dfinjr that is not an ifconfig command
from the main pfsense menu, do 8 and then run the command
-
-
rather so, enter the shell (8)
-
@daddygo
my bad!
-
this looks good....
we're not moving forward, we're stuck in one place, I can think of two things:- do you have a good quality USB NIC in your hands?
- VirtualBox temp install
-
@daddygo
I agree. breaking out another system with mint/virtual box on it to test. stand by for a sec and let me build something up. -
@johnpoz said in VMware Workstation VMs Web Traffic Being Blocked:
Looking at your ciscoasa pcap - the frame sizes are sill OFF.. 1434 and 1380?
Yeah, interesting. Something is restricting the MTU there.
Also interesting is that the pcap on the VM host sees the traffic both ways with the Cisco in there.
Steve
-
While we're waiting...
Would you expect to see a block between two systems on these two vlans?
got something interesting going on here and I wonder if it is the same thing we've been seeing...
As I mentioned once before, I am a Bigfix sales engineer.
The DMZ client can ping/curl everything I would expect for the system to connect to the Bigfix management server yet I am seeing it fail.
-
What's the advanced option you have set on the LABSYSTEMS rule?
I would not expect anything blocked, do you see blocks in the firewall log?
-
@stephenw10
It's likely this, from troubleshooting:Maybe so:
-
You shouldn't need that TCP flags setting unless you have an asymmetric route and it would be a lot more broken if you did.
Those blocked packets look like the host at 10.10.0.10 sending acks after the state has closed, which is usually not an issue.
https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#troubleshooting-blocked-log-entries-for-legitimate-connection-packets -
-
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
Recommendation?
Recommendation!
https://forum.netgate.com/topic/36362/log-shows-tcp-fa-tcp-fpa-blocked-from-lan -
any chance any of you would be in for a direct troubleshooting session with me? I feel like I am burning a lot of your time and I was hoping to speed up the process for us all. If so I was thinking I can host a meeting at 11AM EST over gotomeeting if anyone is interested?
-
You can try setting the firewall optimisation to conservative in Sys > Adv > Firewall&NAT. That gives you longer state timeouts if it needs that.
I really wouldn't expect that though.
If you actually do have some asymmetry there that could explain a number of things. Why you only saw one way traffic on the VMhost NIC for example. But I would expect far more to be broken if that was the case.
Steve
-
@dfinjr said in VMware Workstation VMs Web Traffic Being Blocked:
any chance any of you would be in for a direct troubleshooting session with me?
The truth is that we always say here that others learn from what we write here (forum) and can be retrieved for a long time.
This is why many people (member) use NoChat/NoPM in their signature -
Ok so a few updates have taken place.
First of all:
@DaddyGo
Your virtual box build idea works. All traffic all sites work. Problem is localized to the vm workstation area on that host machine.Firewall to 10.10.0.10:
Still failing to register for unknown reasons after adjusting to conservative.on the live session:
I'd be happy to do a write up from whatever we wall potentially do in this forum post. My goal was only to let you all see first hand what is happening. Happy to keep it here if that is what you all want. Obviously I do not want to ask anyone to do anything they're not comfortable with.Overall I feel like we're getting close to the answer. We know that the vm workstation virtual switching is part of the problem for sure but are still on the mystery why the Cisco ASA was able to cope and route.
This 10.10.0.10 secondary problem is interesting because that is physical > virtual connection where I have that working in a multitude of places outside of that DMZ vlan. A handful of systems are able to effectively do what that DMZ client is failing to do from both the other vlans (labsystems and default)