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

    ICMP NAT

    Scheduled Pinned Locked Moved NAT
    24 Posts 4 Posters 10.3k 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.
    • P
      PurpleOfPants
      last edited by

      I already went over my point about this..  if you send public.100 to private.52 icmp, how do you know if private.82 is online?

      Perhaps something got missed in translation :)

      If I set public.100 icmp to go to private.52 icmp it's because I want to be able to ping private.52 on public.100. Private.82 is then not relevant because I didn't set up a forward to it, and I know I didn't. That's something I would have to bear in mind.

      Let's suppose I am trying to get to www.bbc.co.uk and it's not working. So I ping www.bbc.co.uk to see if the problem is that end. I might try tracert to see how far along the line I can get before getting lost. I don't know the IP address of www.bbc.co.uk although I could look it up, but that's not relevant.

      So, how on earth am I to know that I should ping engineering.bbcworks.co.uk instead? That might be the address of their router and no doubt their techies know about it, but I certainly don't.

      Back to my setup. public.100:80 goes to private.52:80, and public.100:6745 goes to private:82:80. The public webserver on port 80 I want to respond to ping for other users trying to ping the webserver, whereas the private server on port 6745 is only used by me and I'm happy to know what I really need to do.

      The fact that it can't be redirected everywhere isn't a problem. The fact that it can't be redirected somewhere is. As I said, having the router respond when it can't forward is fine, because ultimately the user debugging his link will see the public IP respond and know he can get this far.

      I've had this problem before, where I do a tracert and it stops in the far ISP. Not knowing how the ISP is set up I don't know if that's an ISP problem or if it's the final hop before the destination IP.

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

        "Back to my setup. public.100:80 goes to private.52:80, and public.100:6745 goes to private:82:80. The public webserver on port 80 I want to respond to ping for other users trying to ping the webserver"

        But what does it matter - if public.100 answers ping. Its of little difference if its actually the webserver on private.52 answering the ping or the router.  If the webpage does not work - this doesn't tell the user anything special.

        Just like when you try and ping anything public like www.google.com or something - just because it answers ping does not mean it works, and just because it doesn't answer doesn't mean it doesn't work.

        As long as public.100 answers you know that you have connectivity to the router.  If public.100 answers icmp, you know that you have connectivity to what the public knows as the address.  Be it the router that answers or the private.52 answers – if public.100:80 does not work - what extra info does it answering ping tell the user be it or even the admin.

        Since its a different forward the admin has to still check if router is not forwarding or if private.82 is not listening on 80.

        Just not seeing the point of pinging behind a 1:many nat to be honest.  Now is it technically possible??  Not sure - have never had a need or desire to do such a thing.

        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
        • P
          PurpleOfPants
          last edited by

          But what does it matter - if public.100 answers ping

          That would be OK. The issue is that it doesn't :)

          A few posts up the implication is that it doesn't becuase I'm not using CARP. I don't think I want to use CARP because that is for multi-wan fail-over setups, and that isn't what I have. Should I ignore all that and just use the raw public IP address on my NAT rules?

          Edit: OK, forget that question - I realise it's the wrong thing now. Unfortunately, I left my pfSense book at the client and he's not in a rush to post it back…

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

            It does if you use the correct one - per the previous link I posted too, since your on 2.x according to

            IP Alias

            Available in version 2.0.

            Adds extra IP addresses to an interface.
                Can be used by the firewall itself to run services or be forwarded.
                Will respond to ICMP ping if allowed by firewall rules.

            http://doc.pfsense.org/index.php/What_are_Virtual_IP_Addresses%3F

            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
            • P
              PurpleOfPants
              last edited by

              Yes, my problem now is converting from one to the other. I can't create an IP alias when there is already a virtual IP with that address. Even if I change all references to a specific host address, I can't delete the PARP entry because the address is still referenced by NAT. It looks like I have to vape everything and start again, which I can't do remotely.

              Edit: Duh! I can just go in and edit it, and then it works :)

              Sorry for the aggro of getting to this point. I appreciate your help and patience!

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

                No problem - so your all good now?

                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
                • P
                  PurpleOfPants
                  last edited by

                  Yes, thanks. I am sated :)

                  1 Reply Last reply Reply Quote 0
                  • E
                    Efonnes
                    last edited by

                    If you still want to forward it, it should be fairly easy to just add the option.  Open /usr/local/www/firewall_nat_edit.php, find the string "TCP UDP TCP/UDP GRE ESP" and simply add ICMP to the list, like this: "TCP UDP TCP/UDP GRE ESP ICMP"  I don't think there's anything more to it than that.  Another way would be to manually change the protocol to icmp in the configuration.

                    1 Reply Last reply Reply Quote 0
                    • P
                      PurpleOfPants
                      last edited by

                      Thanks!

                      Ummm… if it's that simple, is there some compelling reason for not allowing it in a distribution? Whilst my immediate problem is resolved, it would be great to be able to ping an actual machine behind a NAT router.

                      1 Reply Last reply Reply Quote 0
                      • P
                        PurpleOfPants
                        last edited by

                        @PurpleOfPants:

                        if it's that simple…

                        For the avoidance of doubt, it is that simple. Fantastic  :-*

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