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

    Traceroute not working from LAN to any Internet destination

    Scheduled Pinned Locked Moved Off-Topic & Non-Support Discussion
    23 Posts 9 Posters 4.4k 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.
    • H
      halfmetaljacket
      last edited by

      Does creation of that rule not introduce a new security risk by allowing any ICMP traffic inbound from the internet? That does not seem like an acceptable workaround to me.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        Well depends how you gauge the risk, responding to pings is not high risk IMO.

        But, yeah, I would not expect to have to allow that. Setting that to OUT only will likely also workaround the problem.

        It's also not set as 'quick' which I would have expected....

        Steve

        N 1 Reply Last reply Reply Quote 0
        • JeGrJ
          JeGr LAYER 8 Moderator
          last edited by

          There are 3-4 ICMP subtypes that should be open per various recommendations and security implications. The last time I checked it was "if one of those 4 get's an attacker inside - you have other problems then ICMP being used."

          A good quick lookup is http://shouldiblockicmp.com/

          For IPv4(legacy) there should be: Type 8/C0 (request), Type 3/C4 (fragreq), Type 11/C0 (timex). This can be reached with ICMP subtype selections: "Echo request", "Destination unreachable" and "Time exceeded" in a IPv4 ICMP rule. We're running that for years in a big datacenter environment - never had problems with it but much more debug capabilities and less problems with other networks upstream.

          Don't forget to upvote 👍 those who kindly offered their time and brainpower to help you!

          If you're interested, I'm available to discuss details of German-speaking paid support (for companies) if needed.

          1 Reply Last reply Reply Quote 0
          • N
            netblues @stephenw10
            last edited by

            @stephenw10 said in Traceroute not working from LAN to any Internet destination:

            Well depends how you gauge the risk, responding to pings is not high risk IMO.

            But, yeah, I would not expect to have to allow that. Setting that to OUT only will likely also workaround the problem.

            It's also not set as 'quick' which I would have expected....

            Steve

            I just run to the same issue running codel on 2.4.5
            And the fix does the job, using direction out and quick

            What do you mean by >It's also not set as 'quick' which I would have expected.... ?

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by stephenw10

              If you don't set the rule as 'quick' traffic matched by it will go on to be parsed by any other rules. Since it has to respond without matching the CoDel Limiter I expect it to require 'quick' there to prevent it being parsed the Limiter rule below it.

              https://docs.netgate.com/pfsense/en/latest/book/firewall/floating-rules.html#quick

              Steve

              1 Reply Last reply Reply Quote 0
              • N
                netblues
                last edited by

                Yes, of course :)
                It doesn't work without quick. Confirmed

                1 Reply Last reply Reply Quote 0
                • D
                  daemonix
                  last edited by daemonix

                  Hi, I have the floating rule and quick but Im getting the same problems. Am I missing something in my rules?!

                  5f123352-ab82-41cc-89ba-561290f487e1-Screenshot 2020-06-13 09.27.31.png

                  traceroute www.ntua.gr
                  traceroute to www.ntua.gr (147.102.224.101), 64 hops max, 52 byte packets
                   1  XX (X)  4.054 ms  1.243 ms  1.275 ms
                   2  www.ntua.gr (147.102.224.101)  8.807 ms  9.811 ms  10.076 ms
                   3  www.ntua.gr (147.102.224.101)  15.286 ms  9.946 ms  9.692 ms
                   4  * * *
                   5  www.ntua.gr (147.102.224.101)  14.548 ms  13.996 ms  13.006 ms
                   6  www.ntua.gr (147.102.224.101)  13.220 ms  15.703 ms  13.044 ms
                   7  * www.ntua.gr (147.102.224.101)  45.182 ms  43.441 ms
                   8  www.ntua.gr (147.102.224.101)  44.675 ms  44.498 ms  47.619 ms
                  
                  1 Reply Last reply Reply Quote 0
                  • N
                    netblues
                    last edited by

                    ca8e612b-ee69-4266-bae3-f8ace3cbcf6a-image.png
                    Don't specify an interface
                    and try moving it up a bit. The vpn egress seems to match traffic.

                    D 1 Reply Last reply Reply Quote 0
                    • D
                      daemonix @netblues
                      last edited by daemonix

                      @netblues the egress is there to stop things going via WAN when the VPN client is down. Shouldnt be first?

                      Updated the rules like this. still the same.

                      Screenshot 2020-06-13 12.20.53.png

                      The other weird thing is that the two codel rules are matching very little compared to what the general "LAN" rule matches on the other tab.. hmmm

                      N 1 Reply Last reply Reply Quote 0
                      • N
                        netblues @daemonix
                        last edited by

                        @daemonix Well, temporarily disable it and see if it matters. Floating rules are powerful but do have side effects.

                        D 1 Reply Last reply Reply Quote 1
                        • D
                          daemonix @netblues
                          last edited by

                          @netblues no fun.. even without it traceroute isnt working.

                          What else it might be?

                          1 Reply Last reply Reply Quote 0
                          • N
                            netblues
                            last edited by stephenw10

                            It just hit me...
                            traceroute on recent linux uses tcp...
                            try: traceroute -I ntua.gr

                            1 Reply Last reply Reply Quote 0
                            • stephenw10S
                              stephenw10 Netgate Administrator
                              last edited by

                              Edited to remove the auto-link.

                              Linux uses UDP by default, yeah.

                              N 1 Reply Last reply Reply Quote 0
                              • N
                                netblues @stephenw10
                                last edited by

                                @stephenw10 -M method, --module=name
                                Use specified method for traceroute operations. Default traditional udp method has name default, icmp (-I) and tcp (-T) have names icmp and tcp respectively.
                                So its udp
                                at the same time. mtr is using icmp. I don't thing there is any workaround for udp traceroute and fq-codel

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

                                  This fixed my traceroute issue, but I do have two questions:

                                  1. Should ICMP type be set to all? Seems like there are other types of ICMP that are valuable to pass through?
                                  2. Is this is a pfSense bug? I don't recall needing this rule before, but perhaps it was because my system was not under load or I did not have limiters enabled?
                                  1 Reply Last reply Reply Quote 0
                                  • stephenw10S
                                    stephenw10 Netgate Administrator
                                    last edited by

                                    https://redmine.pfsense.org/issues/9263

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