internal LAN routing
-
I am trying to understand how pfSense routes LAN addresses. I have LAN interfaces IGB1 with address 192.168.1.1 and mask 255.255.255.0 (/24), and IGB2 with address 192.168.2.1 and mask 255.255.255.0.
When connecting a host to 192.168.1.1 with default gateway 192.168.1.1 and mask 255.255.255.0, I notice that tracert-ing on the host to 192.168.2.1 yields a direct response from 192.168.2.1 and not a response from 192.168.1.1 followed by a response from 192.168.2.1, as I would expect. It seems that pfSense treats all LAN addresses as if they were on the same subnet, despite the /24 masks on the interfaces. What am I missing?
EDIT: On the same setup, tracert to a WAN address works as expected, e.g. for tracert to 8.8.8.8:
- 192.168.1.1
- a.b.c.d [WAN ISP gateway]
3-n. other hops - 8.8.8.8
-
Routers "know" about directly connected subnets. So, when you try to access an address on a different subnet, the packets to go the default route, which is pfsense, and are then automagically forwarded to the appropriate subnet. Now, if you had another subnet connected to one of those directly connected ones, pfsense wouldn't know about it and you'd have to configure a route to it.
-
@jknott : It does seem that that's how it works, but I expected that pfSense would treat 192.168.1.1 as an automagically-generated gateway to 192.168.2.1, thus yielding a tracert of
1. 192.168.1.1 2. 192.168.2.1rather than
1. 192.168.2.1 -
What are the router addresses? If the addresses you listed, then 192.168.2.1 is effectively the same address as 192.168.1.1, as they both point to the same device. BTW, this is a point that really trips up some people on IPv6, where the WAN address is often not the actual routing address and in fact you don't even need a WAN address, as any valid address on the box will do for connecting to it. On IPv6, the link local address is often used for routing, regardless of whether you have a WAN address or not.
-
@jknott said in internal LAN routing:
What are the router addresses? If the addresses you listed, then 192.168.2.1 is effectively the same address as 192.168.1.1, as they both point to the same device.
The WAN interface gets its address via DHCP from the ISP, and is (as is proper) a non-RFC1918 address. My LAN interfaces all have RFC1918 addresses.
-
Again, with NAT, the packet appears to originate at the WAN address, not LAN. Fire up Packet Capture to see that.
Also, you can read about floating rules here.
"Another way to use floating rules is to control traffic leaving from the firewall itself. Floating rules can prevent the firewall from reaching specific IP addresses, ports, and so on." This is the example @johnpoz gave.
-
@bpsdtzpw said in internal LAN routing:
as an automagically-generated gateway to 192.168.2.1, thus yielding a tracert of
Huh.. Where are you doing your traceroute from?? And what are you tracing too?
Here is a trace route from device on my lan 192.168.9.100/24 the gateway to get off this network pfsense is 192.168.9.253 as you can see this
$ tracert 192.168.3.32 Tracing route to ntp.local.lan [192.168.3.32] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms sg4860.local.lan [192.168.9.253] 2 <1 ms <1 ms <1 ms ntp.local.lan [192.168.3.32] Trace complete.If you are seeing only 1 hop from vlan X to an IP on vlan Y.. that is would not be correct no..
But if your tracing to say an IP that is on pfsense directly, then yeah it only is 1 hop to get there. Say when I trace to pfsense IP in the 192.168.3/24 network of 192.168.3.253 from that same 192.168.9.100 machine
$ tracert 192.168.3.253 Tracing route to sg4860.dmz.local.lan [192.168.3.253] over a maximum of 30 hops: 1 <1 ms <1 ms <1 ms sg4860.dmz.local.lan [192.168.3.253] Trace complete.Keep in mind are you tracing via UDP or ICMP.. And what firewall rules are in place, and what your tracing to going to answer your trace? You might not get anything back, or you might get what seems odd back.. For example when I try and trace 192.168.9.100 from my 192.168.3.32 box
root@ntp:/home/pi# traceroute 192.168.9.100 traceroute to 192.168.9.100 (192.168.9.100), 30 hops max, 60 byte packets 1 sg4860.dmz.local.lan (192.168.3.253) 0.488 ms 0.338 ms 0.271 msThis is do to firewall rules and it using udp vs icmp, etc..
Here I edited rules on that dmz interface to allow for ICMP and then did traceroute via ICMP
traceroute to 192.168.9.100 (192.168.9.100), 30 hops max, 60 byte packets 1 sg4860.dmz.local.lan (192.168.3.253) 0.486 ms 0.593 ms 0.282 ms root@ntp:/home/pi# traceroute -I 192.168.9.100 traceroute to 192.168.9.100 (192.168.9.100), 30 hops max, 60 byte packets 1 sg4860.dmz.local.lan (192.168.3.253) 0.504 ms 0.410 ms 0.388 ms 2 i5-win.local.lan (192.168.9.100) 0.695 ms 0.678 ms 0.660 ms root@ntp:/home/pi#Here I edit to allow for UDP which is what linux traceroute uses by default
traceroute to 192.168.9.100 (192.168.9.100), 30 hops max, 60 byte packets 1 sg4860.dmz.local.lan (192.168.3.253) 0.466 ms 0.320 ms 0.265 ms 2 * i5-win.local.lan (192.168.9.100) 0.620 ms * root@ntp:/home/pi#Happy to help you work out why your seeing what your seeing, or how to allow to see what you want to see, etc. traceroute is more complex than many users realize.
-
@johnpoz said in internal LAN routing:
But if your tracing to say an IP that is on pfsense directly, then yeah it only is 1 hop to get there.
Yes, that's what I'm seeing. I don't have any VLANs setup, just different subnets on different LAN interfaces, e.g., igb1 is 192.168.1.1/24 and igb2 is 192.168.2.1/24. In this case, tracert-ing 192.168.2.1 from 192.168.1.10 (a host connected to igb1) yields
1. 192.168.2.1which I thought was curious. I had expected
1. 192.168.1.1 2. 192.168.2.1Thanks for the explanation.
-
@bpsdtzpw said in internal LAN routing:
which I thought was curious. I had expected
- 192.168.1.1
- 192.168.2.1
As I mentioned before, those are the same device, so only one hop. This is the way all routing works, not just with pfsense.
