Static route between 2 pfSense
-
There should be no reason to NAT between those two networks.
Do not set gateways on the transit interfaces themselves. They should just be enabled and have IP addresses and netmasks. You create a gateway in System > Routing but do not place it on the interfaces themselves.
If there is outbound NAT for your transit interfaces, disable or delete those rules.
Not exactly sure what you're talking about with the ESXi address. Routing doesn't care how the addresses are assigned. The ESXi host needs to allow traffic from the remote subnets and have 172.25.22.1 as its default gateway. Same with any VMs you place on the 172.25.22.0/24 vSwitch.
I have a similar setup with a transit network between two pfsense and the only way hosts from a LAN behind pfSense 1 can get to hosts on the LAN behind pfSense 2 is if I assign the gateway in the transit interfaces.
-
Then you are doing it wrong.
In the diagram above:
On pfSense 1:
Make an interface for TRANSIT with 10.0.0.1/29
Make sure firewall rules on TRANSIT pass desirable traffic from TRANSIT Net and 192.168.5.0/24
System > Routing Make a gateway TRANSIT_GW on TRANSIT for 10.0.0.2
System > Routing Make a static route for 192.168.5.0/24 to TRANSIT_GWOn pfSense 2:
Make an interface for TRANSIT with 10.0.0.2/29
Make sure firewall rules on TRANSIT pass desirable traffic from TRANSIT Net and 172.25.22.0/24
System > Routing Make a gateway TRANSIT_GW on TRANSIT for 10.0.0.1
System > Routing Make a static route for 172.25.22.0/24 to TRANSIT_GWAnd you're done.
If that does not work there is, perhaps, some policy routing on the LAN interfaces that needs to be bypassed.
-
Then you are doing it wrong.
In the diagram above:
On pfSense 1:
Make an interface for TRANSIT with 10.0.0.1/29
Make sure firewall rules on TRANSIT pass desirable traffic from TRANSIT Net and 192.168.5.0/24
System > Routing Make a gateway TRANSIT_GW on TRANSIT for 10.0.0.2
System > Routing Make a static route for 192.168.5.0/24 to TRANSIT_GWOn pfSense 2:
Make an interface for TRANSIT with 10.0.0.2/29
Make sure firewall rules on TRANSIT pass desirable traffic from TRANSIT Net and 172.25.22.0/24
System > Routing Make a gateway TRANSIT_GW on TRANSIT for 10.0.0.1
System > Routing Make a static route for 172.25.22.0/24 to TRANSIT_GWAnd you're done.
If that does not work there is, perhaps, some policy routing on the LAN interfaces that needs to be bypassed.
Thanks for the reply. That's exactly the way I had it, but I'll doublecheck the FW rules just in case. I'm using a /30 network for the transit network with 10.10.10.1 and 10.10.10.2 on each end, but that should not make a difference.
-
/30 is, of course, just fine.
Putting a gateway on an interface makes pfSense treat it as a WAN which is probably not what you want.
That would enable reply-to on inbound states which might mask if there was a static route in only one direction.
-
/30 is, of course, just fine.
Putting a gateway on an interface makes pfSense treat it as a WAN which is probably not what you want.
That would enable reply-to on inbound states which might mask if there was a static route in only one direction.
You were 100% right! On pfSense 2 the static route to the LAN behind pfSense 1 had a typo ::) . Fixed that, removed the gateways from both the transit interfaces' settings and everything is working.
Thanks!
-
Excellent!
-
I know this is super old, but I have a variation on this issue.
I have an internal IP that is hooked up to another system as well, however it is not PF Sense on that side. Also, routes have been learned via RIPv2 so I don't really know how to handle the Gateway static entries, as they are not static. Any advice?
I should also say, I can reach the RIP learned routes on all internal parts of the different router interfaces. The only problem is behind the other router, it cannot get beyond PF sense hence no Internet access. I did a traceroute from one of the end points on the RIP learned routes, and internet bound traffic dies upon reaching the PF Sense interface.
-
RIPv2? Really?
-
Well, not to go into too long of a story, this is an old TDMA iDirect satellite system in which they did some really stupid networking things like using RIPv2 and even proxy ARP. Not under my control.
I've attached a diagram. So behind the RHEL server, new subnets are created fairly frequently and in order to inform the world of their creation, they are updated via RIPv2 on the front end of the RHEL server. This is actually much more fairly involved thing involving some other moving parts, but I believe this is the relevant to PFsense portion.
So my issue is, once a new subnet is created, PF is picking it via RIP but for some reason hosts on the private subnets behind the RHEL can't get anywhere on the Internet; inside any of my private nets yes, it works fine. My workaround for now was to add a GW to PF indicating specific manually added static routes for the private nets that lay behind the GW (10.10.1.11) and the route to it. For example I've added the GW RHEL and then put routes behind it for example to 192.168.1.0/24. This works ok (although for some reason DNS is not passing, but one thing at time). Just want to see if it's possible to do this same thing via RIP. It doesn't seem to work the way it is now
-
You probably need to add outbound NAT for all of the private subnets on pfSense WAN.
Manually adding the static routes very likely enabled pfSense to know what networks were downstream so they were picked up by Automatic Outbound NAT.
Nothing like that is possible when pfSense doesn't have the routes in the configuration since they are dynamically-learned.
-
Seems to have auto-added them. The static route addition seemed to probably cause the auto-generation. However, DNS isn't passing all the way down for some reason. The other subnets are on other interfaces that I didn't show on the picture.
-
Sorry. No idea what "DNS isn't passing down" means. Need to know where the DNS clients are, what their configured name servers are, and what is not working to be able to have a chance at helping.
-
Sorry, the 192.168.1.0/24 subnet now passes traffic after I added the static route, but is not resolving DNS.
So, if you're a client on 192.168.1.0/24, no DNS resolution. I tried putting PF Sense as the DNS IP (10.10.1.1) and also directly to the DNS provider and no luck.
I'm still experimenting with this so I'll get back to you before I ask it again. I made a rule to tag DNS pass traffic on that interface to see if it's getting to PF via log checking. Will post when I see what's up.
