Routing between interfaces not working
-
Hello,
So I have a PFsense setup with multiple interfaces. On prior firewalls, providing firewall rules allow it, the client PCs have been able to:
- Ping the IP address of the interfaces on the firewall (This is working now)
- Ping the destination IP of a remote device by routing via the interfaces on the firewall (This is NOT working).
A simple overview of what I'm seeing at the moment.
Client PC - 192.168.100.20
Firewall Interfaces:
- 192.168.100.254
- 192.168.200.254
Destination PC - 192.168.200.20
I have allowed ICMP on both LAN interfaces on the PFsense.
The Client PC is able to ping the firewall interfaces:
- 192.168.100.254
- 192.168.200.254
However it is NOT able to ping:
Destination PC - 192.168.200.20
What am I missing, or what does PFsenses do differently do other firewalls?
-
@Matt_Sharpe
Ensure that pfSense is the default gateway on both devices.If this is given and the rules to pass the traffic are set properly, I'd guess, that the destination device is blocking the access by its own firewall.
-
@viragomann the PFsense in question is not the destination default gateway. However the prior firewall we used was the same networking information, also not the default gateway on the example target device.
The local firewall on the endpoint is turned off, so not causing any issues.
-
@Matt_Sharpe said in Routing between interfaces not working:
the PFsense in question is not the destination default gateway. However the prior firewall we used was the same networking information
It could have done NAT / masquerading, then you can also access to other network segment if the route is not the default gateway on it.
I saw consumer routers, which do this by default. However, it's a security issue in fact. -
@viragomann Is there a way to mimic this on PFsense or work around the issue of adding manual routes on destination devices or destination routers?
-
@Matt_Sharpe
You can do the with an outbound NAT rule. Firewall > NAT > Outbound.Switch it into hybrid mode, save this, then add a rule:
interface: the one facing to the destination device
source: any or source PC (for a single IP, select network and state a /32 mask)
destination: destination device
translation: interface address (default) -
@viragomann said in Routing between interfaces not working:
interface: the one facing to the destination device
Would this be the source interface, or the interface with an IP address on the target network?
translation: interface address (default)
Would we not be better choosing a specific interface here?
-
@Matt_Sharpe your interface for the outbound nat be your interface in this destination network on pfsense where clients are not pointing to pfsense for their gateway.
Here is an example.
So anything wanting to talk to something on my test network from the lan network would look like it comes from pfsense test IP..
You could be more selective in the nat, like a specifc lan IP or to a specific or list of IPs on your destination network that don't have their gateway set to pfsense.
-
@Matt_Sharpe said in Routing between interfaces not working:
@viragomann said in Routing between interfaces not working:
interface: the one facing to the destination device
Would this be the source interface, or the interface with an IP address on the target network?
This one, which the target device is connected to.
translation: interface address (default)
Would we not be better choosing a specific interface here?
"interface address" is specific at all. Why aren't happy with it?
This rule translate the source IP in packets destined to the IPs at "destination" to the interface IP. So the destination device response back to pfSense instead of its default gateway.
Otherwise you would need to add a static route on the destination device. -
@viragomann said in Routing between interfaces not working:
Otherwise you would need to add a static route on the destination device.
Yup that is another way to work the problem.
-
@johnpoz @viragomann appreciate your help so far! I didn't have a reason for prior question, just trying to understand :)
So I've already had it working via a static route on a destination test VM in PowerShell, but of course not ideal when you're talking about an entire range of clients.
I've recreated the NAT rule but still no joy.
Interface = Destination INTERFACE
Source = Source LAN range
Source Port = *
Destination = Destination LAN range
Destination port = *
NAT Address = Interface Address (automatically configured to Destination interface address)
NAT Port = *I am testing with ICMP which I have allowed any/any on both Source/Destination firewall interfaces...
-
@Matt_Sharpe you would need to make sure your using a new state, so it would be translated.. if reusing an old state it wouldn't be natted to your destination network pfsense IP.
-
@johnpoz A reboot and it appears to now be working on my test! Is there a quicker/less invasive way to clear/reset the states?
-
@Matt_Sharpe yeah a reboot is sledgehammer approach ;)
Burning the house down to kill the spider comes to mind
You can look in your state table for the specific states and kill them, or you can reset all states in the state table as well. No need to nuke it from orbit - even if the only way to be sure ;)
-
@Matt_Sharpe
Diagnostic > States -
@johnpoz Yeah, this is not live it's in a testing state. However a reboot takes the same amount of time a reply takes so thought it's worth an initial attempt haha.
-
@johnpoz @viragomann one thing I've noticed, the firewalls I'm testing with are in a HA pair. If I reboot them, the CARP kicks in but it appears the states are lost/having issues failing over as they appear to drop on reboot... ? Latest reboot, one of the 2 networks stayed up pinging, but the other timed out and not come back. It will come back however if I manually terminate the state...
