Static route not applied.
-
I have setup a pfsense machine with the following configuration:
WAN: 10.50.0.7 igb0
LAN: 10.40.70.200 igb2I have also setup 2 gateways. A default gateway and a second gateway to a specific network range.
default gw: 10.50.0.200
client gw: 10.50.0.4I added the static route:
10.40.40.0/24 via 10.50.0.4From the pfsense, a traceroute to 10.40.40.200 goes thru the default gw, rather than the client gw.
ROUTING TABLE
Internet:
Destination Gateway Flags Netif Expire
default 10.50.0.200 UGS igb0
10.40.40.0/24 10.50.0.4 UGS igb0
10.40.70.0/24 link#11 U igb2.40
gw00 link#11 UHS lo0
10.50.0.0/24 link#1 U igb0
10.50.0.7 link#1 UHS lo0
10.50.70.0/24 link#3 U igb2
10.50.70.200 link#3 UHS lo0
localhost link#8 UH lo0[2.6.0-RELEASE][@gw00. traceroute 10.40.40.200
traceroute to 10.40.40.200 (10.40.40.200), 64 hops max, 40 byte packets
1 10.50.0.201 (10.50.0.201) 0.223 ms 0.218 ms 0.222 msI would have expected the connection to fgo via 10.50.0.4, as this route is setup. What am I missing?
-
@conejero said in Static route not applied.:
From the pfsense, a traceroute to 10.40.40.200 goes thru the default gw, rather than the client gw.
Well something is off here, your trace is going to
1 10.50.0.201 (10.50.0.201) 0.223 ms 0.218 ms 0.222 ms
.201, not .200 like you stated your gateway is, and your route table shows. Got some typos in trying to obfuscate IPs?
-
@johnpoz 10.50.0.200 is a CARP address. 10.50.0.201 is the first machine on the CARP group.
Again, the question is, if the routing table states:
10.40.40.0/24 10.50.0.4 UGS igb0Why is ping to 10.40.40.200 NOT going thru 10.50.0.4 as specified on the routing table?
-
@conejero do you show the gateway online?
I can create an arbitrary gateway and send too it without any issues.
So while my windows machine at 192.168.9.100 isn't going to route anything, and can not get its firewall to send a reject for a udp traceroute, etc.
If I create a gateway, and route clearly pfsense when doing a ping sends it to my 192.168.9.100 box.. As you can see in the sniff I did on pfsense when doing a ping from pfsense to 10.40.40.1
-
@johnpoz gateway is online. There is no packet loss.
-
@conejero the only thing is that both gateways belong to the same network, unlike in your example.
-
@conejero Multiple gateways/routers on the WAN get problematic because of route-to/reply-to.
If you look in your rule set you will see a rule that forces everything that goes out WAN to anything but a destination on the WAN subnet out to
(route-to 10.50.0.200)If you want to try something, remove the gateway from your WAN interface itself. This will break things like automatic outbound NAT because pfSense will no longer see igb0 as a "WAN" interface so you'll need to manually add NAT rules. But it will remove the
route-torules from the WAN. If you switch to manual NAT before removing the gateway from the WAN interface configuration all of the automatic rules will be automatically switched to manual rules first.Another, possibly better soution would be to make a transit network to the router at 10.50.0.4 if possible and get it off WAN altogether.
-
@conejero Well I could create a route to some other IP in my wan network to better try to duplicate your issue.. But here I created to gateways in the same network, and different routes per each gateway. And they are followed.
You can see depending on where I try and ping, the traffic goes to different gateway.
My overall point was routing is working as given, and I can not seem to duplicate your issue. So we missing part of the puzzle.
edit: looks like Derelict jumped in with what your problem most likely.
-
@derelict I removed the gateway setting from the interface WAN. I left the default gw as it was, on 10.50.0.200
Now the static routes work properly. I am not all that familiar with FreeBSD. Is there a corresponding "ip rule list" command to print current rule sets?@derelict thank you for your help.
-
@conejero Easiest way is
cat /tmp/rules.debugfor the most human-friendly version. You can alsopfctl -vvsrto see the raw rule set but it is broken down a lot more that way. It's generally not necessary to look there to get a picture of the rules and what they are doing.
