Routing between interfaces not working
-
@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...
