Virtualized PFsense - host (linux) cannot ping Pfsense Wan Interface (and vice-versa) - Not rule related
-
Hello
The host and the guest share the same WAN interface (bridged) and are on the same ip subnet. They cannot ping each other.
The host and the guest also share the same LAN interface (bridged) and are on the same ip subnet. They ping each other successfully.
Firewall rules any-any were created on both WAN interface and floating rules, but WAN ping does not work, while LAN ping does work.
Steps already taken:
1- Allow bogon and private networks on WAN interface
2 - Allow icmp rules any-any on WAN interface
3 - PFsense WAN interface can ping other devices that exist on its subnetAny ideas? Thanks
-
@spyshagg
If the WAN network has a private IP range you have also uncheck "Block private IPs" in the WAN interface settings. -
@viragomann said in Virtualized PFsense - host (linux) cannot ping Pfsense Wan Interface (and vice-versa) - Not rule related:
@spyshagg
If the WAN network has a private IP range you have also uncheck "Block private IPs" in the WAN interface settings.Hi
Yes its also unchecked.
-
@spyshagg
Possibly there is something blocking the traffic in the hypervisor.Sniff the traffic on pfSense WAN interface (Diagnistic > Packet Capture) to ensure that the packets are even arriving on the interface.
-
@viragomann said in Virtualized PFsense - host (linux) cannot ping Pfsense Wan Interface (and vice-versa) - Not rule related:
@spyshagg
Possibly there is something blocking the traffic in the hypervisor.Sniff the traffic on pfSense WAN interface (Diagnistic > Packet Capture) to ensure that the packets are even arriving on the interface.
The packet capture tells me the ping requests are not arriving on the interface. Strange.
But the same happens in Virtualbox and KVM, two different VM platforms. It suggest its not the hypervisor?
-
-
@spyshagg
When there are no packets on the WAN interface, there is not really much you can do from the view of pfSense, except the VM configuration.Did you obey the set up instruction for virtualized platforms from the pfSense docs?
-
@viragomann said in Virtualized PFsense - host (linux) cannot ping Pfsense Wan Interface (and vice-versa) - Not rule related:
@spyshagg
When there are no packets on the WAN interface, there is not really much you can do from the view of pfSense, except the VM configuration.Did you obey the set up instruction for virtualized platforms from the pfSense docs?
Yes.
But its odd that ping works on the LAN interface but not on WAN, when both interfaces are setup the same on KVM/Virtualbox.
-
@spyshagg said in Virtualized PFsense - host (linux) cannot ping Pfsense Wan Interface (and vice-versa) - Not rule related:
The host and the guest also share the same LAN interface (bridged)
Hypervisor access from the lan sounds normal to me. It also sounds like this is working.
@spyshagg said in Virtualized PFsense - host (linux) cannot ping Pfsense Wan Interface (and vice-versa) - Not rule related:
The host and the guest share the same WAN interface (bridged)
Why are you doing that. Most setups want the hypervisor only directly accessible from the lan interface and often only the lan management interface. If you need hypervisor access from the internet then via vpn on your router makes more sense to me.
I suspect your hypervisor is blocking wan access by default.
-
@spyshagg said in Virtualized PFsense - host (linux) cannot ping Pfsense Wan Interface (and vice-versa) - Not rule related:
But its odd that ping works on the LAN interface but not on WAN
Indeed. Are both networks configured properly on all involved devices?
Also ensure that the packets on the host are going out on the correct interface by sniffing the traffic.
-
@patch said in Virtualized PFsense - host (linux) cannot ping Pfsense Wan Interface (and vice-versa) - Not rule related:
Why are you doing that. Most setups want the hypervisor only directly accessible from the lan interface and often only the lan management interface. If you need hypervisor access from the internet then via vpn on your router makes more sense to me.
I suspect your hypervisor is blocking wan access by default.
Its a last desperate measure. Sometimes one of the virtual nics stops passing traffic into Pfsense. Sometimes Wan, sometimes Lan.
I am building a watchdog that runs on the host to ping both pfsense interfaces and reset the VM if they fail. -
@spyshagg said in Virtualized PFsense - host (linux) cannot ping Pfsense Wan Interface (and vice-versa) - Not rule related:
Sometimes one of the virtual nics stops passing traffic into Pfsense. Sometimes Wan, sometimes Lan.
I am building a watchdog that runs on the host to ping both pfsense interfaces and reset the VM if they fail.It would be better to eliminate the real reason for this than doing a workaround by restarting the VM.
-
@viragomann said in Virtualized PFsense - host (linux) cannot ping Pfsense Wan Interface (and vice-versa) - Not rule related:
@spyshagg said in Virtualized PFsense - host (linux) cannot ping Pfsense Wan Interface (and vice-versa) - Not rule related:
Sometimes one of the virtual nics stops passing traffic into Pfsense. Sometimes Wan, sometimes Lan.
I am building a watchdog that runs on the host to ping both pfsense interfaces and reset the VM if they fail.It would be better to eliminate the real reason for this than doing a workaround by restarting the VM.
sadly its not physically possible.
-
@spyshagg
YukAs a desperate measure I would prefer:
- using pass through NICs for pfsense.
- Monitoring the interfaces within pfsense and
- resetting them via an pfsense watchdog / interface monitor if required.
But whatever works
-
@patch said in Virtualized PFsense - host (linux) cannot ping Pfsense Wan Interface (and vice-versa) - Not rule related:
@spyshagg
YukAs a desperate measure I would prefer:
- using pass through NICs for pfsense.
- Monitoring the interfaces within pfsense and
- resetting them via an pfsense watchdog / interface monitor if required.
But whatever works
Hardware and software configuration are not possible at this point. The problem manifested itself 3 full weeks after deployment and not in the 2 weeks of internal testing prior to deployment.
A simple reset does not fix the issue. The vm must be shutdown and restarted.
It appears the problem is indeed with the hypervisor blocking packets.
thank guys