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

    PfSense not showing in traceroute

    Scheduled Pinned Locked Moved Problems Installing or Upgrading pfSense Software
    8 Posts 4 Posters 2.8k 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.
    • R
      Rewt0r
      last edited by

      Hi,

      Having a problem when performing a traceroute to a Virtual IP address with a nat 1:1. The local machine that's assigned to the 1:1 shows up twice at the end of the traceroute but the hop for the pfSense box isn't shown e.g.:

      13 30ms 32ms 31ms my-server.co.uk
      14 30ms 32ms 31ms my-server.co.uk

      Performing a traceroute from that local machine to my IP address correctly shows the first hop as the pfSense box, performing a traceroute to the public IP of the pfSense box also works as expected.

      Any ideas?

      1 Reply Last reply Reply Quote 0
      • P
        phil.davis
        last edited by

        NAT happens very early on when an incoming packet arrives (i.e. before ordinary firewall rules - which need to use the NATed destination when trying to match…). So by the time the incoming traceroute packet has been allowed into the firewall (pfSense) the destination address has already been changed by the NAT rule from the public-facing IP to the internal IP. Then (on hop 13 in your example) the TTL goes to zero and I guess pfSense responds with the TTL-expired packet, but as if it was from the NATed destination.
        Then for TTL=14 the packet gets all the way to the real destination, which also replies with its (same as hop 13) address.
        Thus the hop points look the same on 13 and 14.

        As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
        If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

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

          That's how things should work in that scenario. It does show, it's the second to last hop. The last hop is the system behind the 1:1 NAT, which gets translated back to the public IP again, which is why it shows twice. First is pfSense itself, second is the system behind the 1:1.

          1 Reply Last reply Reply Quote 0
          • P
            phil.davis
            last edited by

            cmb is correct, my explanation is a bit round the wrong way - even though each hop is NATed in to the private side of pfSense, on the way back out the replies are "unNATed" back to the public-facing IP. So replies from both hops 13 and 14 are seen as coming from the public-facing IP, which reverse-resolves to the public name.

            As the Greek philosopher Isosceles used to say, "There are 3 sides to every triangle."
            If I helped you, then help someone else - buy someone a gift from the INF catalog http://secure.inf.org/gifts/usd/

            1 Reply Last reply Reply Quote 0
            • R
              Rewt0r
              last edited by

              But pfSense is setup to use a WAN IP different to the external IP it's replying with in the traceroute, surely it should be using that IP on hop 13?

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

                @Rewt0r:

                But pfSense is setup to use a WAN IP different to the external IP it's replying with in the traceroute, surely it should be using that IP on hop 13?

                Not where that VIP is assigned as CARP or IP alias, in that case it's a local IP to it and will reply with that. If it were being routed through and no local binding, that's how it would behave.

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

                  Sorry for pulling up this old thread again.

                  Just recognized that with 2.3.1_1 it looks like something regarding this behaviour has been changed.

                  Previously when using 1:1 NAT with additional IPs, the WAN IP was included within the traceroute like this:

                  …
                  12.  last-hop.our-isp.com  1.2.3.4
                  13.  our-wan-gw.corp.com 2.2.2.2
                  14.  our-web-server.corp.com 2.2.2.3

                  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

                  I reviewed all the tickets assigned to 2.3.1_1 but i could not find any relevant code changes.

                  Any hints why this behaviour may have changed?  Just for interest.

                  Thanks

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

                    push.

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