Network Management

NetPath graph issue: All timeout nodes from an intermediate node to endpoint

How to troubleshoot a graph issue where between the NetPath probe and the last internal node, NetPath only captures timeout node(s).

First published date

10/9/2018 4:17 PM

Last published date

5/11/2026 11:31 PM

Overview

The NetPath graph seems to be missing Internet nodes.

NetPath only captures timeout nodes between the endpoint and the last internal node.

Product section

Network Performance Monitor

Cause

 

    Resolution

    Step 1: Check if the last visible intermediate node is a firewall or the router right before the firewall

    Is it a firewall?

    Step 2: Check if the firewall is creating logs for NetPath probing packets

    1. Find the endpoint IP address and TCP port from the service that has the issue.
    2. Find the IP address of the NetPath agent that probes the service.
    3. Locate the firewall that the NetPath probing traffic traverses. The firewall may or may not display in the NetPath graph.
    4. Make sure the log is enabled for Drop rules, including Default and Implicit Drop rules.
    5. Based on the firewall manual:
      1. For the outbound direction from agent to endpoint, find the firewall drop logs for TCP packets from the IP address of the NetPath agent and any source port, to the endpoint IP address and port of the service with the issue.
      2. For the inbound direction from endpoint to agent, find the firewall drop logs for ICMP Type 11 packets from any IP address to the IP address of the NetPath agent.

    Check firewall logs

    Open Check Point SmartView Tracker > All Records > Add filters.
    For outbound NetPath probing packets, add the filter for:

    • Service: TCP service specified in NetPath Services
    • Source: NetPath probe
    • Destination: Endpoint

    For inbound NetPath probing packets, add the filter for:

    • ICMP Type 11
    • Destination: NetPath probe]

    Note: The log option must be enabled for rules that can allow or deny NetPath probing traffic.

    Palo Alto



    SonicWall



    Cisco ASA



    Did you find the logs?

    • Yes: This is a potential firewall issue. Locate the drop rule from the log and consult with a firewall engineer to fix it.
    • No: Go to Step 3.

    Step 3: Check if the IP address ID masking rule is enabled for a Check Point firewall

    1. Open the Check Point SmartDashboard.
    2. Navigate to IPS > Protections.
    3. Search for IP ID Masking.
    4. Check if the rule is Active.

    Is the IP ID masking rule enabled?

    • Yes: Add the IP address of the NetPath probe to the exception: Edit IP ID Masking > Network Exceptions > New > Add NetPath Probe to Source Network Condition.
    • No: Go to Step 4.
    • I don't have a Check Point firewall: Go to Step 4.

    Step 4: Capture the outbound NetPath TCP probing packet at the inside interface of the firewall

    1. Find the IP address and TCP port from the service that has issue.
    2. Find the IP address of the NetPath agent that probes the service.
    3. Locate the inside interface where the NetPath probing traffic is expected to enter the firewall.
    4. Refer to the firewall manual, and execute the command to capture TCP packets on the inside interface with matching criteria: from the IP address of the NetPath agent and any source port, to the IP address and port of the service with the issue.

    Examples for packet capture commands:

    Were the packets captured?

    Step 5: Capture the outbound NetPath TCP probing packet at the outside interface of the firewall

    1. Find the IP address and TCP port from the service that has issue.
    2. Find the IP address of the NetPath agent that probes the service.
    3. Find the source NAT IP address if the source address translation applies to NetPath TCP probing packets.
    4. Locate the outside interface where the NetPath probing traffic is expected to exit the firewall.
    5. Refer to the firewall manual, and execute the command to capture TCP packets on the outside interface with matching criteria: from the IP address of the NetPath agent (or IP address of the source NAT IP address) and any source port, to the IP address and port of the service with the issue.

    Were the packets captured?

    • Yes: Go to Step 6.
    • No: NetPath TCP probing packets did not traverse the firewall. This is a potential firewall issue. Consult with a firewall engineer to fix it.

    Step 6: Capture the inbound NetPath ICMP Type 11 packets at the outside interface of the firewall

    1. Find the IP address of the NetPath agent that probes the service.
    2. Find the source NAT IP address if the source address translation applies to outbound NetPath TCP probing packets.
    3. Locate the outside interface where the inbound ICMP Type 11 packets are expected to enter the firewall.
    4. Refer to the firewall manual, and execute the command to capture ICMP Type 11 packets on the outside interface with matching criteria: from any IP address to the IP address of the source NAT IP address.

    Were the packets captured?

    • Yes: Go to Step 7.
    • No: NetPath expects ICMP Type 11 packets, which did not reach the firewall. This is a potential firewall issue at the upstream firewalls. Consult with a firewall engineer to fix it.

    Step 7: Capture the inbound NetPath ICMP Type 11 packets at the inside interface of the firewall

    1. Find the IP address of the NetPath agent that probes the service.
    2. Locate the inside interface where the inbound ICMP packets are expected to exit the firewall.
    3. Refer to the firewall manual, and execute the command to capture ICMP Type 11 packets on the inside interface with matching criteria: from any IP address to the IP address of the NetPath agent.

    Were the packets captured?

    • Yes: Submit a ticket to technical support.
    • No: NetPath expects ICMP Type 11 packets, which did not traverse the firewall. This is a potential firewall issue. Consult with a firewall engineer to fix it.

    Special cases for Cisco firewalls