IP Routing in 2.0 RC3
-
Hello
I am in the process of testing pfsense for deployment however have very strange results when setting up ip routing on the system.
I have added the route (10.0.0.0/8 172.29.1.10) and you will see on the traceroute it does not goto the 172.29.1.10 as the first hop it goes to the default gateway (172.29.1.1)!? You will see below the route table and traceroute results.
If there is anything I can do to provide more information I am more than happy to help.
[2.0-RC3][admin@pfsense.localdomain]/root(3): netstat -rn
Routing tablesInternet:
Destination Gateway Flags Refs Use Netif Expire
default 172.29.1.1 UGS 0 355198 em0
10.0.0.0/8 172.29.1.10 UGS 0 106 em0
127.0.0.1 link#4 UH 0 195 lo0
172.29.1.0/24 link#1 U 0 42374 em0
172.29.1.63 link#1 UHS 0 0 lo0
172.29.2.0/24 172.29.1.10 UGS 0 222 em0
192.168.100.0/24 link#3 U 0 316259 em2
192.168.100.1 link#3 UHS 0 0 lo0Internet6:
Destination Gateway Flags Netif Expire
::1 ::1 UH lo0
fe80::%em0/64 link#1 U em0
fe80::213:72ff:fe4f:b772%em0 link#1 UHS lo0
fe80::%em2/64 link#3 U em2
fe80::20e:cff:fea9:a3b3%em2 link#3 UHS lo0
fe80::%lo0/64 link#4 U lo0
fe80::1%lo0 link#4 UHS lo0
ff01:1::/32 fe80::213:72ff:fe4f:b772%em0 U em0
ff01:3::/32 fe80::20e:cff:fea9:a3b3%em2 U em2
ff01:4::/32 ::1 U lo0
ff02::%em0/32 fe80::213:72ff:fe4f:b772%em0 U em0
ff02::%em2/32 fe80::20e:cff:fea9:a3b3%em2 U em2
ff02::%lo0/32 ::1 U lo0
[2.0-RC3][admin@pfsense.localdomain]/root(4):[2.0-RC3][admin@pfsense.localdomain]/root(4): traceroute 10.30.0.151
traceroute to 10.30.0.151 (10.30.0.151), 64 hops max, 40 byte packets
1 172.29.1.1 (172.29.1.1) 1.103 ms 0.476 ms 0.475 ms
2 172.29.1.10 (172.29.1.10) 0.971 ms 0.930 ms 0.977 ms
3 *^C
[2.0-RC3][admin@pfsense.localdomain]/root(5):
[2.0-RC3][admin@pfsense.localdomain]/root(5): -
Do you have any policy routing in place?
Other than that you'd have to explain your setup more to have the right answer.
One suggestion out of nowhere is to add a rule in floating rules with direction out and destination your static route destination. -
Thank you for the response. I did try it with policy routing and without, however. Another google search of the forums have found that setting 'Bypass firewall rules for traffic on the same interface' will (and has) corrected this behaviour.