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

    Is Ping Smart?

    Scheduled Pinned Locked Moved General pfSense Questions
    4 Posts 2 Posters 1.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.
    • B
      bsmither
      last edited by

      I've made these tests according to this chart:

      pfSense 2.0: WAN (down), LAN (10.1.10.5/24), OPT (10.2.10.5/24)

      Clients: LAP1 and BLK (on LAN); BLU (on OPT)

      Firewall Rules:
      OPT tab:

      • OPT net * LAN net * *
      • OPT net * * * *
        I don't know if the second rule is necessary as of yet.

      LAN tab:

          • LAN Address 80 * * (Anti-Lockout Rule)
      • LAN net * * * *

      I have Wireshark on LAP1 capturing all ICMP packets.

      LAP1 -> BLK: request sent and reply received (OK, both on LAN)
      LAN -> LAP1: request received and reply sent (from ping diag page)
      LAP1 -> OPT: request sent only but no reply received (cannot tell if OPT chose to reply)
      BLU -> LAP1: request received but no reply sent (firewall rule OK)

      The actual question is: If LAP1 somehow knows it cannot reach BLU, will LAP1 even try to reply?

      Follow-on question: If BLU on OPT can get a packet through the firewall to LAP1 on LAN, will I need a corresponding rule on LAN to OPT for the reply. Is this not automatic?

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

        @bsmither:

        The actual question is: If LAP1 somehow knows it cannot reach BLU, will LAP1 even try to reply?

        It will if its routing table has a path to reach that host (assuming no firewall on that host is blocking it). If a host gets an ICMP echo request (ping), it will send back an echo reply as long as the source of the request is reachable per the OS's routing table. If it has no means of reaching that network via its routing table, it won't reply as it can't send the reply anywhere.

        @bsmither:

        Follow-on question: If BLU on OPT can get a packet through the firewall to LAP1 on LAN, will I need a corresponding rule on LAN to OPT for the reply. Is this not automatic?

        No. Replies are allowed by the state the request creates.

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

          @cmb:

          If a host gets an ICMP echo request (ping), it will send back an echo reply as long as the source of the request is reachable per the OS's routing table. If it has no means of reaching that network via its routing table, it won't reply as it can't send the reply anywhere.

          Thank you for the reply. It is much appreciated.

          So, just to satisfy my curiosity, is it the ICMP protocol's job to determine if a reply can be sent without a route, or is it the networking part of the OS, or the ping.exe application?

          The way I see it, something has to be dumb enough to permit a reply based on knowing the IP address and/or the MAC address of the sender in the request packet.

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

            @bsmither:

            So, just to satisfy my curiosity, is it the ICMP protocol's job to determine if a reply can be sent without a route, or is it the networking part of the OS, or the ping.exe application?

            The way I see it, something has to be dumb enough to permit a reply based on knowing the IP address and/or the MAC address of the sender in the request packet.

            It's the IP stack of the OS. It has to be able to send back to the source IP of the request, whether it's locally reachable (so it just ARPs that IP), or is reachable via some router in its routing table (in which case it ARPs the router where that IP is reachable per its routing table).

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