Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    internal LAN routing

    Scheduled Pinned Locked Moved General pfSense Questions
    9 Posts 3 Posters 1.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • B
      bPsdTZpW
      last edited by bPsdTZpW

      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:

      1. 192.168.1.1
      2. a.b.c.d [WAN ISP gateway]
        3-n. other hops
      3. 8.8.8.8
      1 Reply Last reply Reply Quote 1
      • JKnottJ
        JKnott
        last edited by

        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.

        PfSense running on Qotom mini PC
        i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
        UniFi AC-Lite access point

        I haven't lost my mind. It's around here...somewhere...

        B 1 Reply Last reply Reply Quote 0
        • B
          bPsdTZpW @JKnott
          last edited by

          @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.1
          

          rather than

          1. 192.168.2.1
          
          JKnottJ johnpozJ 2 Replies Last reply Reply Quote 1
          • JKnottJ
            JKnott @bPsdTZpW
            last edited by

            @bpsdtzpw

            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.

            PfSense running on Qotom mini PC
            i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
            UniFi AC-Lite access point

            I haven't lost my mind. It's around here...somewhere...

            B 1 Reply Last reply Reply Quote 0
            • B
              bPsdTZpW @JKnott
              last edited by

              @jknott said in internal LAN routing:

              @bpsdtzpw

              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.

              JKnottJ 1 Reply Last reply Reply Quote 0
              • JKnottJ
                JKnott @bPsdTZpW
                last edited by

                @bpsdtzpw

                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.

                PfSense running on Qotom mini PC
                i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                UniFi AC-Lite access point

                I haven't lost my mind. It's around here...somewhere...

                1 Reply Last reply Reply Quote 0
                • johnpozJ
                  johnpoz LAYER 8 Global Moderator @bPsdTZpW
                  last edited by johnpoz

                  @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 ms
                  

                  This 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.

                  An intelligent man is sometimes forced to be drunk to spend time with his fools
                  If you get confused: Listen to the Music Play
                  Please don't Chat/PM me for help, unless mod related
                  SG-4860 24.11 | Lab VMs 2.8, 24.11

                  1 Reply Last reply Reply Quote 0
                  • B
                    bPsdTZpW
                    last edited by

                    @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.1
                    

                    which I thought was curious. I had expected

                    1. 192.168.1.1
                    2. 192.168.2.1
                    

                    Thanks for the explanation.

                    JKnottJ 1 Reply Last reply Reply Quote 0
                    • JKnottJ
                      JKnott @bPsdTZpW
                      last edited by

                      @bpsdtzpw said in internal LAN routing:

                      which I thought was curious. I had expected

                      1. 192.168.1.1
                      2. 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.

                      PfSense running on Qotom mini PC
                      i5 CPU, 4 GB memory, 32 GB SSD & 4 Intel Gb Ethernet ports.
                      UniFi AC-Lite access point

                      I haven't lost my mind. It's around here...somewhere...

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.