Navigation

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

    1:1 NAT and traceroutes since 2.3.1_1

    General pfSense Questions
    3
    7
    1451
    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.
    • ?
      Guest last edited by

      With 2.3.1_1 it looks like something regarding NAT/Traceroutes has been changed.

      Previously when using 1:1 NAT with additional IPs, the Main WAN IP of the pfSense box was included within the traceroute as penultimate hop like this:

      …
      12.  last-hop.our-isp.com  1.2.3.4
      13.  our-pfsense-box.corp.com 2.2.2.2 <--- pfSense Main Public IP
      14.  our-web-server.corp.com 2.2.2.3 <--- 1:1 NATed host with Public IP behind pfSense

      Now with 2.3.1_1 all of a sudden the traces look like this:

      ...
      12.  last-hop.our-isp.com  1.2.3.4
      13.  our-web-server.corp.com 2.2.2.3 <--- 1:1 NATed host with Public IP behind pfSense

      The traceroutes are performed over WAN and not from LAN-to-WAN behind pfsense.

      Any hints why this behaviour may have changed?  Just for interest and to know if there's a particular setting for that.

      Thanks

      1 Reply Last reply Reply Quote 0
      • chpalmer
        chpalmer last edited by

        Was the same here.  Now I actually see my VIP show up twice as the last two hops.

        Triggering snowflakes one by one..

        1 Reply Last reply Reply Quote 0
        • ?
          Guest last edited by

          @chpalmer:

          Was the same here.  Now I actually see my VIP show up twice as the last two hops.

          Can confirm that with ICMP traceroute. I'll see the VIP twice aswell.

          1 Reply Last reply Reply Quote 0
          • C
            cmb last edited by

            Might have changed in FreeBSD 10.3, so 2.3.0+, but nothing specific there that changed as far as I'm aware. The last 2 hops on a traceroute to a 1:1 NATed IP have generally always showed the VIP twice. Once on the reply from the firewall itself, once on the reply from the host behind the 1:1 NAT.

            1 Reply Last reply Reply Quote 0
            • chpalmer
              chpalmer last edited by

              @cmb:

              The last 2 hops on a traceroute to a 1:1 NATed IP have generally always showed the VIP twice. Once on the reply from the firewall itself, once on the reply from the host behind the 1:1 NAT.

              If its the "firewall itself" wouldn't that mean the primary WAN address?

              Not a big issue to me but just noticing.  Ive never seen my VIP show up twice in the past when testing.

              https://doc.pfsense.org/index.php?title=What_are_Virtual_IP_Addresses%3F        " Will respond to ICMP ping if allowed by firewall rules"  If I have 1:1 NAT for the VIP then wouldn't any traffic pointed at my VIP go directly to the LAN address behind the firewall?  I have rules in place on the WAN and they have the LAN address for my server for "Destination" but no rules allowing the ICMP to the VIP as destination.

              Wouldn't I instead see a "Block" in my logs with the VIP as destination for that particular attempt?      *  *  *    in my Windows command window tracert reply??

              Just trying to understand.  :)


              Triggering snowflakes one by one..

              1 Reply Last reply Reply Quote 0
              • C
                cmb last edited by

                @chpalmer:

                " Will respond to ICMP ping if allowed by firewall rules"  If I have 1:1 NAT for the VIP then wouldn't any traffic pointed at my VIP go directly to the LAN address behind the firewall?

                Yes, the "will respond to ping" is re: the more common use of not 1:1 NATing, if the ping matches any NAT rule, then it'll be forwarded to the internal host, the firewall itself won't reply to traffic destined to that IP. But it will reply with TTL exceeded in the case of traceroute. It sounds like something changed behavior there in FreeBSD 10.3 so it's translating the TTL exceeded where it previously did not.

                1 Reply Last reply Reply Quote 0
                • ?
                  Guest last edited by

                  Thanks for the clarification cmb.

                  Noticed that when doing a ICMP traceroute it currently looks like this with 1:1 NAT and a ICMP-req permit any ingress rule:

                  
                  root@mybox:~$ traceroute -P ICMP www.mycorp.com
                  traceroute to www.mycorp.com (178.29.55.4), 64 hops max, 72 byte packets
                   1  192.168.0.1 (192.168.0.1)  4.286 ms  0.853 ms  0.793 ms
                   2  * * *
                   3  * * *
                   ....
                  12  isp-gw.isp.com (178.29.55.1) 37.324 ms 36.232 ms 37.232 ms
                  13  web.mycorp.com (178.29.55.101)  38.349 ms  37.285 ms  37.907 ms   <--- this would probably be the pfSense box at 178.29.55.100
                  14  web.mycorp.com (178.29.55.101)  37.661 ms  37.410 ms  36.496 ms
                  
                  

                  So yes, it really seems that Freebsd 10.3 changed something.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post