Fortinet black logo

Administration Guide

Checking routing

Checking routing

ping and traceroute are useful tools in network connectivity and route troubleshooting.

Since you typically use these tools to troubleshoot, you can allow ICMP, the protocol used by these tools, in firewall policies and on interfaces only when you need them. Otherwise, disable ICMP for improved security and performance.

By default, the FortiWeb appliance will forward only HTTP/HTTPS traffic to your protected web servers. (That is, routing/IP-based forwarding is disabled.) For information on enabling forwarding of FTP or other protocols, see the config router setting command in the FortiWeb CLI Reference:

HTTPs://docs.fortinet.com/product/fortiweb/

By default, FortiWeb appliances will respond to ping and traceroute. However, if the appliance does not respond, and there are no firewall policies that block it, ICMP type 0 (ECHO_REPSPONSE) might be effectively disabled.

To enable ping and traceroute responses from FortiWeb
  1. Go to System > Network > Interface.
  2. To access this part of the web UI, you must have Read and Write permission in your administrator's account access profile to items in the Router Configuration category. For details, see Permissions.

  3. In the row for the network interface which you want to respond to ICMP type 8 (ECHO_REQUEST) for ping and UDP for traceroute, click Edit.
  4. A dialog appears.

  5. Enable PING.
  6. Disabling PING only prevents FortiWeb from receiving ICMP type 8 (ECHO_REQUEST) and traceroute-related UDP and responding to it.

    It does not disable FortiWeb CLI commands such as execute ping or execute traceroute that send such traffic.

  7. If Trusted Host, Administrators, and Administrators have been restricted, verify that they include your computer or device’s IP address. Otherwise FortiWeb will not respond.
  8. Click OK.
  9. The appliance should now respond when another device such as your management computer sends a ping or traceroute to that network interface.

To verify routes between clients and your web servers
  1. Attempt to connect through the FortiWeb appliance, from a client to a protected web server, via HTTP and/or HTTPS.
  2. If the connectivity test fails, continue to the next step.

  3. Use the ping command on both the client and the server to verify that a route exists between the two. Test traffic movement in both directions: from the client to the server, and the server to the client. Web servers do not need to be able to initiate a connection, but must be able to send reply traffic along a return path.
  4. In networks using features such as asymmetric routing, routing success in one direction does not guarantee success in the other.

    If the routing test succeeds, continue with For application-layer problems, on the FortiWeb, examine the:.

    If the routing test fails, continue to the next step.

  5. Use the tracert or traceroute command on both the client and the server (depending on their operating systems) to locate the point of failure along the route.
  6. If the route is broken when it reaches the FortiWeb appliance, first examine its network interfaces and routes. To display network interface addresses and subnets, enter the CLI command:

    show system interface


    To display all recently-used routes with their priorities, enter the CLI command:

    diagnose network route list


    You may need to verify that the physical cabling is reliable and not loose or broken, that there are no IP address or MAC address conflicts or blocklisting, misconfigured DNS records, and otherwise rule out problems at the physical, network, and transport layer.

    If these tests succeed, a route exists, but you cannot connect using HTTP or HTTPS, an application-layer problem is preventing connectivity.

  7. For application-layer problems, on the FortiWeb, examine the:
  • matching server policy and all components it references
  • certificates (if connecting via HTTPS)
  • web server service/daemon (it should be running, and configured to listen on the port specified in the server policy for HTTP and/or HTTPS, for virtual hosts, they should be configured with a correct Host: name)

On routers and firewalls between the host and the FortiWeb appliance, verify that they permit HTTP and/or HTTPS connectivity between them.

Testing for connectivity with ping

The ping command sends a small data packet to the destination and waits for a response. The response has a timer that may expire, indicating that the destination is unreachable via ICMP.

Connectivity via ICMP only proves that a route exists. It does not prove that connectivity also exists via other protocols at other layers such as HTTP.

ICMP is part of Layer 3 on the OSI Networking Model. ping sends Internet Control Message Protocol (ICMP) ECHO_REQUEST (“ping”) packets to the destination, and listens for ECHO_RESPONSE (“pong”) packets in reply.

Some networks block ICMP packets because they can be used in a ping flood or denial of service (DoS) attack if the network does not have anti-DoS capabilities, or because ping can be used by an attacker to find potential targets on the network.

Beyond basic existence of a possible route between the source and destination, ping tells you the amount of packet loss (if any), how long it takes the packet to make the round trip (latency), and the variation in that time from packet to packet (jitter).

If ping shows some packet loss, investigate:

  • cabling to eliminate loose connections
  • ECMP, split horizon, or network loops
  • all equipment between the ICMP source and destination to minimize hops

If ping shows total packet loss, investigate:

  • cabling to eliminate incorrect connections
  • all firewalls, routers, and other devices between the two locations to verify correct IP addresses, routes, MAC lists, trusted hosts, and policy configurations

If ping finds an outage between two points, use traceroute to locate exactly where the problem is.

To ping a device from the FortiWeb CLI
  1. Log in to the CLI via either SSH, Telnet, or you can ping from the FortiWeb appliance in the CLI Console accessed from the web UI.
  2. If you want to adjust the behavior of execute ping, first use the execute ping options command. For details, see the FortiWeb CLI Reference:
  3. HTTPs://docs.fortinet.com/product/fortiweb/

  4. Enter the command:
  5. execute ping <destination_ipv4>

    where <destination_ipv4> is the IP address of the device that you want to verify that the appliance can connect to, such as 192.168.1.1.

    To verify that routing is bidirectionally symmetric, you should also ping the appliance. For details, see To enable ping and traceroute responses from FortiWeb and To ping a device from a Microsoft Windows computer or To ping a device from a Linux or Mac OS X computer.

    If the appliance can reach the host via ICMP, output similar to the following appears:

    PING 192.0.2.96 (192.0.2.96): 56 data bytes

    64 bytes from 192.0.2.96: icmp_seq=0 ttl=253 time=6.5 ms

    64 bytes from 192.0.2.96: icmp_seq=1 ttl=253 time=7.4 ms

    64 bytes from 192.0.2.96: icmp_seq=2 ttl=253 time=6.0 ms

    64 bytes from 192.0.2.96: icmp_seq=3 ttl=253 time=5.5 ms

    64 bytes from 192.0.2.96: icmp_seq=4 ttl=253 time=7.3 ms

    --- 192.0.2.96 ping statistics ---

    5 packets transmitted, 5 packets received, 0% packet loss

    round-trip min/avg/max = 5.5/6.5/7.4 ms

    If the appliance cannot reach the host via ICMP, output similar to the following appears:

    PING 192.0.2.108 (192.0.2.108): 56 data bytes

    Timeout ...

    Timeout ...

    Timeout ...

    Timeout ...

    Timeout ...

    --- 192.0.2.108 ping statistics ---

    5 packets transmitted, 0 packets received, 100% packet loss


    “100% packet loss” and “Timeout” indicates that the host is not reachable.

    For details, see the FortiWeb CLI Reference:

    HTTPs://docs.fortinet.com/product/fortiweb/

To ping a device from a Microsoft Windows computer
  1. Click the Start (Windows logo) menu to open it.
  2. If the host is running Windows XP, instead, go to Start > Run...

  3. Type cmd then press Enter.

    The Windows command line appears.

  4. Enter the command:

    ping <options_str> <destination_ipv4>


    where:

    • <destination_ipv4> is the IP address of the device that you want to verify that the computer can connect to, such as 192.0.2.1.
    • <options_str> are zero or more options, such as:
      • -t—Send packets until you press Control-C.
      • -a—Resolve IP addresses to domain names where possible.
      • -n x—Where x is the number of packets to send.

    For example, you might enter:

    ping -n 5 192.0.2.1


    If the computer can reach the destination, output similar to the following appears:

    Pinging 192.0.2.1 with 32 bytes of data:

    Reply from 192.0.2.1: bytes=32 time=7ms TTL=253

    Reply from 192.0.2.1: bytes=32 time=6ms TTL=253

    Reply from 192.0.2.1: bytes=32 time=11ms TTL=253

    Reply from 192.0.2.1: bytes=32 time=5ms TTL=253

    Ping statistics for 192.0.2.1:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

    Minimum = 5ms, Maximum = 11ms, Average = 7ms


    If the computer cannot reach the destination, output similar to the following appears:

    Pinging 192.0.2.1 with 32 bytes of data:

    Request timed out.

    Request timed out.

    Request timed out.

    Request timed out.

    Ping statistics for 192.0.2.1:

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

    “100% loss” and “Request timed out.” indicates that the host is not reachable.

To ping a device from a Linux or Mac OS X computer
  1. Open a command prompt.
  2. Alternatively, on Mac OS X, you can use the Network Utility application.
  3. Enter the following command:
  4. ping <options_str> <destination_ipv4>

    where:

  • <destination_ipv4> is the IP address of the device that you want to verify that the computer can connect to, such as 192.0.2.1.
  • <options_str> are zero or more options, such as:
    • -W y—Wait y seconds for ECHO_RESPONSE.
    • -c x—Where x is the number of packets to send.

If the command is not found, you can either enter the full path to the executable or add its path to your shell environment variables. The path to the ping executable varies by distribution, but may be /bin/ping.

If you do not supply a packet count, output will continue until you terminate the command with Control-C. For more information on options, enter man ping.

For example, you might enter:

ping -c 5 -W 2 192.0.2.1


If the computer can reach the destination via ICMP, output similar to the following appears:

PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.

64 bytes from 192.0.2.1: icmp_seq=1 ttl=253 time=6.85 ms

64 bytes from 192.0.2.1: icmp_seq=2 ttl=253 time=7.64 ms

64 bytes from 192.0.2.1: icmp_seq=3 ttl=253 time=8.73 ms

64 bytes from 192.0.2.1: icmp_seq=4 ttl=253 time=11.0 ms

64 bytes from 192.0.2.1: icmp_seq=5 ttl=253 time=9.72 ms

--- 192.0.2.1 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4016ms

rtt min/avg/max/mdev = 6.854/8.804/11.072/1.495 ms


If the computer cannot reach the destination via ICMP, if you specified a wait and packet count rather than having the command wait for your Control-C, output similar to the following appears:

PING 192.0.2.15 (192.0.2.15) 56(84) bytes of data.

--- 192.0.2.15 ping statistics ---

5 packets transmitted, 0 received, 100% packet loss, time 5999ms

“100% packet loss” indicates that the host is not reachable.


Otherwise, if you terminate by pressing Control-C (^C), output similar to the following appears:

PING 192.0.2.15 (192.0.2.15) 56(84) bytes of data.

From 192.0.2.2 icmp_seq=31 Destination Host Unreachable

From 192.0.2.2 icmp_seq=30 Destination Host Unreachable

From 192.0.2.2 icmp_seq=29 Destination Host Unreachable

^C

--- 192.0.2.15 ping statistics ---

41 packets transmitted, 0 received, +9 errors, 100% packet loss, time 40108ms

pipe 3

“100% packet loss” and “Destination Host Unreachable” indicates that the host is not reachable.

Testing routes & latency with traceroute

traceroute sends ICMP packets to test each hop along the route. It sends three packets to the destination, and then increases the time to live (TTL) setting by one, and sends another three packets to the destination. As the TTL increases, packets go one hop farther along the route until they reach the destination.

Most traceroute commands display their maximum hop count—the maximum number of steps it will take before declaring the destination unreachable—before they start tracing the route. The TTL setting may result in routers or firewalls along the route timing out due to high latency.

Where ping only tells you if the signal reached its destination and returned successfully, traceroute shows each step of its journey to its destination and how long each step takes. If you specify the destination using a domain name, the traceroute output can also indicate DNS problems, such as an inability to connect to a DNS server.

By default, traceroute uses UDP with destination ports numbered from 33434 to 33534. The traceroute utility usually has an option to specify use of ICMP ECHO_REQUEST (type 8) instead, as used by the Windows tracert utility. If you have a firewall and you want traceroute to work from both machines (Unix-like systems and Windows) you will need to allow both protocols inbound through your firewall (UDP ports 33434 - 33534 and ICMP type 8).

To trace the route to a device from the FortiWeb CLI
  1. Log in to the CLI via either SSH, Telnet, or you can ping from the FortiWeb appliance in the CLI Console widget of the web UI.
  2. Enter the command:
  3. execute traceroute {<destination_ipv4> | <destination_fqdn>}


    where {<destination_ipv4> | <destination_fqdn>} is a choice of either the device’s IP address or its fully qualified domain name (FQDN).

    For example, you might enter:

    execute traceroute www.example.com


    If the appliance has a complete route to the destination, output similar to the following appears:

    traceroute to www.fortinet.com (192.0.2.150), 32 hops max, 84 byte packets

    1 192.0.2.87 0 ms 0 ms 0 ms

    2 192.0.2.221 <static-209-87-254-221.storm.ca> 2 ms 2 ms 2 ms

    3 192.0.2.129 <core-2-g0-1-1104.storm.ca> 2 ms 1 ms 2 ms

    4 192.0.2.161 2 ms 2 ms 3 ms

    5 192.0.2.17 <core2-ottawa23_POS13-1-0.net.bell.ca> 3 ms 3 ms 2 ms

    6 192.0.2.234 <core2-ottawatc_POS5-0-0.net.bell.ca> 20 ms 20 ms 20 ms

    7 192.0.2.58 <core4-toronto21_POS0-12-4-0.net.bell.ca> 24 ms 21 ms 24 ms

    8 192.0.2.154 <bx4-toronto63_so-2-0-0-0.net.bell.ca> 8 ms 9 ms 8 ms

    9 192.0.2.145 <bx2-ashburn_so2-0-0.net.bell.ca> 23 ms 23 ms 23 ms

    10 192.0.2.9 23 ms 22 ms 22 ms

    11 192.0.2.238 <cr2.wswdc.ip.att.net> 100 ms 192.0.2.130 <cr2.wswdc.ip.att.net> 101 ms 102 ms

    12 192.0.2.21 <cr1.cgcil.ip.att.net> 101 ms 100 ms 99 ms

    13 192.0.2.121 <cr1.sffca.ip.att.net> 100 ms 98 ms 100 ms

    14 192.0.2.118 <cr81.sj2ca.ip.att.net> 98 ms 98 ms 100 ms

    15 192.0.2.105 <gar2.sj2ca.ip.att.net> 96 ms 96 ms 96 ms

    16 192.0.2.42 94 ms 94 ms 94 ms

    17 192.0.2.10 88 ms 87 ms 87 ms

    18 192.0.2.130 90 ms 89 ms 90 ms

    19 192.0.2.150 <fortinet.com> 91 ms 89 ms 91 ms

    20 192.0.2.150 <fortinet.com> 91 ms 91 ms 89 ms


    Each line lists the routing hop number, the IP address and FQDN (if any) of that hop, and the 3 response times from that hop. Typically a value of <1ms indicates a local router.

    If the appliance does not have a complete route to the destination, output similar to the following appears:

    traceroute to 192.0.2.1 (192.0.2.1), 32 hops max, 84 byte packets

    1 192.0.2.2 0 ms 0 ms 0 ms

    2 192.0.2.10 0 ms 0 ms 0 ms

    3 * * *

    4 * * *


    The asterisks ( * ) indicate no response from that hop in the network routing. For details, see the FortiWeb CLI Reference:

    HTTPs://docs.fortinet.com/product/fortiweb/

To trace the route to a device from a Microsoft Windows computer
  1. Click the Start (Windows logo) menu to open it.
  2. If the host is running Windows XP, instead, go to Start > Run...

  3. Type cmd then press Enter.
  4. The Windows command line appears.

  5. Enter the command:
  6. tracert {<destination_ipv4> | <destination_fqdn>}

    If the appliance has a complete route to the destination, output similar to the following appears:

    Tracing route to www.fortinet.com [192.0.2.34]

    over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms 192.0.2.2

    2 2 ms 2 ms 2 ms static-192-0-2-221.storm.ca [192.0.2.221]

    3 2 ms 2 ms 22 ms core-2-g0-1-1104.storm.ca [192.0.2.129]

    4 3 ms 3 ms 2 ms 67.69.228.161

    5 3 ms 2 ms 3 ms core2-ottawa23_POS13-1-0.net.bell.ca [192.0.2.17]

    (Output abbreviated.)

    15 97 ms 97 ms 97 ms gar2.sj2ca.ip.att.net [192.0.2.105]

    16 94 ms 94 ms 94 ms 192.0.2.42

    17 87 ms 87 ms 87 ms 192.0.2.10

    18 89 ms 89 ms 90 ms 192.0.2.130

    19 89 ms 89 ms 90 ms fortinet.com [192.0.2.34]

    20 90 ms 90 ms 91 ms fortinet.com [192.0.2.34]

    Trace complete.


    Each line lists the routing hop number, the 3 response times from that hop, and the IP address and FQDN (if any) of that hop. Typically a value of <1ms indicates a local router.

    If the appliance does not have a complete route to the destination, output similar to the following appears:

    Tracing route to 192.0.2.1 over a maximum of 30 hops

    1 <1 ms <1 ms <1 ms 192.0.2.2

    2 <1 ms <1 ms <1 ms 192.0.2.10

    3 * * * Request timed out.

    4 * * * Request timed out.

    5 ^C


    The asterisks ( * ) and “Request timed out.” indicate no response from that hop in the network routing.

To trace the route to a device from a Linux or Mac OS X computer
  1. Open a command prompt.
  2. Alternatively, on Mac OS X, you can use the Network Utility application.
  3. Enter:
  4. traceroute {<destination_ipv4> | <destination_fqdn>}


    Note: the path to the executable may vary by distribution.

    If the appliance has a complete route to the destination, output similar to the following appears:

    traceroute to www.fortinet.com (192.0.2.34), 30 hops max, 60 byte packets

    1 192.0.2.2 (192.0.2.2) 0.189 ms 0.277 ms 0.226 ms

    2 static-192-0-2-221.storm.ca (192.0.2.221) 2.554 ms 2.549 ms 2.503 ms

    3 core-2-g0-1-1104.storm.ca (192.0.2.129) 2.461 ms 2.516 ms 2.417 ms

    4 192.0.2.161 (192.0.2.161) 3.041 ms 3.007 ms 2.966 ms

    5 core2-ottawa23_POS13-1-0.net.bell.ca (192.0.2.17) 3.004 ms 2.998 ms 2.963 ms

    (Output abbreviated.)

    16 192.0.2.42 (192.0.2.42) 94.379 ms 94.114 ms 94.162 ms

    17 192.0.2.10 (192.0.2.10) 122.879 ms 120.690 ms 119.049 ms

    18 192.0.2.130 (203.78.181.130) 89.705 ms 89.411 ms 89.591 ms

    19 fortinet.com (192.0.2.34) 89.717 ms 89.584 ms 89.568 ms


    Each line lists the routing hop number, the IP address and FQDN (if any) of that hop, and the 3 response times from that hop. Typically a value of <1ms indicates a local router.

    If the appliance does not have a complete route to the destination, output similar to the following appears:

    traceroute to 192.0.2.1 (192.0.2.1), 30 hops max, 60 byte packets

    1 * * *

    2 192.0.2.10 (192.0.2.10) 4.160 ms 4.169 ms 4.144 ms

    3 * * *

    4 * * *^C


    The asterisks ( * ) indicate no response from that hop in the network routing.

    Relatedly, if the computer’s DNS query cannot resolve the host name, output similar to the following appears:

    example.lab: Name or service not known

    Cannot handle "host" cmdline arg `example.lab' on position 1 (argc 1)

Checking routing

ping and traceroute are useful tools in network connectivity and route troubleshooting.

Since you typically use these tools to troubleshoot, you can allow ICMP, the protocol used by these tools, in firewall policies and on interfaces only when you need them. Otherwise, disable ICMP for improved security and performance.

By default, the FortiWeb appliance will forward only HTTP/HTTPS traffic to your protected web servers. (That is, routing/IP-based forwarding is disabled.) For information on enabling forwarding of FTP or other protocols, see the config router setting command in the FortiWeb CLI Reference:

HTTPs://docs.fortinet.com/product/fortiweb/

By default, FortiWeb appliances will respond to ping and traceroute. However, if the appliance does not respond, and there are no firewall policies that block it, ICMP type 0 (ECHO_REPSPONSE) might be effectively disabled.

To enable ping and traceroute responses from FortiWeb
  1. Go to System > Network > Interface.
  2. To access this part of the web UI, you must have Read and Write permission in your administrator's account access profile to items in the Router Configuration category. For details, see Permissions.

  3. In the row for the network interface which you want to respond to ICMP type 8 (ECHO_REQUEST) for ping and UDP for traceroute, click Edit.
  4. A dialog appears.

  5. Enable PING.
  6. Disabling PING only prevents FortiWeb from receiving ICMP type 8 (ECHO_REQUEST) and traceroute-related UDP and responding to it.

    It does not disable FortiWeb CLI commands such as execute ping or execute traceroute that send such traffic.

  7. If Trusted Host, Administrators, and Administrators have been restricted, verify that they include your computer or device’s IP address. Otherwise FortiWeb will not respond.
  8. Click OK.
  9. The appliance should now respond when another device such as your management computer sends a ping or traceroute to that network interface.

To verify routes between clients and your web servers
  1. Attempt to connect through the FortiWeb appliance, from a client to a protected web server, via HTTP and/or HTTPS.
  2. If the connectivity test fails, continue to the next step.

  3. Use the ping command on both the client and the server to verify that a route exists between the two. Test traffic movement in both directions: from the client to the server, and the server to the client. Web servers do not need to be able to initiate a connection, but must be able to send reply traffic along a return path.
  4. In networks using features such as asymmetric routing, routing success in one direction does not guarantee success in the other.

    If the routing test succeeds, continue with For application-layer problems, on the FortiWeb, examine the:.

    If the routing test fails, continue to the next step.

  5. Use the tracert or traceroute command on both the client and the server (depending on their operating systems) to locate the point of failure along the route.
  6. If the route is broken when it reaches the FortiWeb appliance, first examine its network interfaces and routes. To display network interface addresses and subnets, enter the CLI command:

    show system interface


    To display all recently-used routes with their priorities, enter the CLI command:

    diagnose network route list


    You may need to verify that the physical cabling is reliable and not loose or broken, that there are no IP address or MAC address conflicts or blocklisting, misconfigured DNS records, and otherwise rule out problems at the physical, network, and transport layer.

    If these tests succeed, a route exists, but you cannot connect using HTTP or HTTPS, an application-layer problem is preventing connectivity.

  7. For application-layer problems, on the FortiWeb, examine the:
  • matching server policy and all components it references
  • certificates (if connecting via HTTPS)
  • web server service/daemon (it should be running, and configured to listen on the port specified in the server policy for HTTP and/or HTTPS, for virtual hosts, they should be configured with a correct Host: name)

On routers and firewalls between the host and the FortiWeb appliance, verify that they permit HTTP and/or HTTPS connectivity between them.

Testing for connectivity with ping

The ping command sends a small data packet to the destination and waits for a response. The response has a timer that may expire, indicating that the destination is unreachable via ICMP.

Connectivity via ICMP only proves that a route exists. It does not prove that connectivity also exists via other protocols at other layers such as HTTP.

ICMP is part of Layer 3 on the OSI Networking Model. ping sends Internet Control Message Protocol (ICMP) ECHO_REQUEST (“ping”) packets to the destination, and listens for ECHO_RESPONSE (“pong”) packets in reply.

Some networks block ICMP packets because they can be used in a ping flood or denial of service (DoS) attack if the network does not have anti-DoS capabilities, or because ping can be used by an attacker to find potential targets on the network.

Beyond basic existence of a possible route between the source and destination, ping tells you the amount of packet loss (if any), how long it takes the packet to make the round trip (latency), and the variation in that time from packet to packet (jitter).

If ping shows some packet loss, investigate:

  • cabling to eliminate loose connections
  • ECMP, split horizon, or network loops
  • all equipment between the ICMP source and destination to minimize hops

If ping shows total packet loss, investigate:

  • cabling to eliminate incorrect connections
  • all firewalls, routers, and other devices between the two locations to verify correct IP addresses, routes, MAC lists, trusted hosts, and policy configurations

If ping finds an outage between two points, use traceroute to locate exactly where the problem is.

To ping a device from the FortiWeb CLI
  1. Log in to the CLI via either SSH, Telnet, or you can ping from the FortiWeb appliance in the CLI Console accessed from the web UI.
  2. If you want to adjust the behavior of execute ping, first use the execute ping options command. For details, see the FortiWeb CLI Reference:
  3. HTTPs://docs.fortinet.com/product/fortiweb/

  4. Enter the command:
  5. execute ping <destination_ipv4>

    where <destination_ipv4> is the IP address of the device that you want to verify that the appliance can connect to, such as 192.168.1.1.

    To verify that routing is bidirectionally symmetric, you should also ping the appliance. For details, see To enable ping and traceroute responses from FortiWeb and To ping a device from a Microsoft Windows computer or To ping a device from a Linux or Mac OS X computer.

    If the appliance can reach the host via ICMP, output similar to the following appears:

    PING 192.0.2.96 (192.0.2.96): 56 data bytes

    64 bytes from 192.0.2.96: icmp_seq=0 ttl=253 time=6.5 ms

    64 bytes from 192.0.2.96: icmp_seq=1 ttl=253 time=7.4 ms

    64 bytes from 192.0.2.96: icmp_seq=2 ttl=253 time=6.0 ms

    64 bytes from 192.0.2.96: icmp_seq=3 ttl=253 time=5.5 ms

    64 bytes from 192.0.2.96: icmp_seq=4 ttl=253 time=7.3 ms

    --- 192.0.2.96 ping statistics ---

    5 packets transmitted, 5 packets received, 0% packet loss

    round-trip min/avg/max = 5.5/6.5/7.4 ms

    If the appliance cannot reach the host via ICMP, output similar to the following appears:

    PING 192.0.2.108 (192.0.2.108): 56 data bytes

    Timeout ...

    Timeout ...

    Timeout ...

    Timeout ...

    Timeout ...

    --- 192.0.2.108 ping statistics ---

    5 packets transmitted, 0 packets received, 100% packet loss


    “100% packet loss” and “Timeout” indicates that the host is not reachable.

    For details, see the FortiWeb CLI Reference:

    HTTPs://docs.fortinet.com/product/fortiweb/

To ping a device from a Microsoft Windows computer
  1. Click the Start (Windows logo) menu to open it.
  2. If the host is running Windows XP, instead, go to Start > Run...

  3. Type cmd then press Enter.

    The Windows command line appears.

  4. Enter the command:

    ping <options_str> <destination_ipv4>


    where:

    • <destination_ipv4> is the IP address of the device that you want to verify that the computer can connect to, such as 192.0.2.1.
    • <options_str> are zero or more options, such as:
      • -t—Send packets until you press Control-C.
      • -a—Resolve IP addresses to domain names where possible.
      • -n x—Where x is the number of packets to send.

    For example, you might enter:

    ping -n 5 192.0.2.1


    If the computer can reach the destination, output similar to the following appears:

    Pinging 192.0.2.1 with 32 bytes of data:

    Reply from 192.0.2.1: bytes=32 time=7ms TTL=253

    Reply from 192.0.2.1: bytes=32 time=6ms TTL=253

    Reply from 192.0.2.1: bytes=32 time=11ms TTL=253

    Reply from 192.0.2.1: bytes=32 time=5ms TTL=253

    Ping statistics for 192.0.2.1:

    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),

    Approximate round trip times in milli-seconds:

    Minimum = 5ms, Maximum = 11ms, Average = 7ms


    If the computer cannot reach the destination, output similar to the following appears:

    Pinging 192.0.2.1 with 32 bytes of data:

    Request timed out.

    Request timed out.

    Request timed out.

    Request timed out.

    Ping statistics for 192.0.2.1:

    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

    “100% loss” and “Request timed out.” indicates that the host is not reachable.

To ping a device from a Linux or Mac OS X computer
  1. Open a command prompt.
  2. Alternatively, on Mac OS X, you can use the Network Utility application.
  3. Enter the following command:
  4. ping <options_str> <destination_ipv4>

    where:

  • <destination_ipv4> is the IP address of the device that you want to verify that the computer can connect to, such as 192.0.2.1.
  • <options_str> are zero or more options, such as:
    • -W y—Wait y seconds for ECHO_RESPONSE.
    • -c x—Where x is the number of packets to send.

If the command is not found, you can either enter the full path to the executable or add its path to your shell environment variables. The path to the ping executable varies by distribution, but may be /bin/ping.

If you do not supply a packet count, output will continue until you terminate the command with Control-C. For more information on options, enter man ping.

For example, you might enter:

ping -c 5 -W 2 192.0.2.1


If the computer can reach the destination via ICMP, output similar to the following appears:

PING 192.0.2.1 (192.0.2.1) 56(84) bytes of data.

64 bytes from 192.0.2.1: icmp_seq=1 ttl=253 time=6.85 ms

64 bytes from 192.0.2.1: icmp_seq=2 ttl=253 time=7.64 ms

64 bytes from 192.0.2.1: icmp_seq=3 ttl=253 time=8.73 ms

64 bytes from 192.0.2.1: icmp_seq=4 ttl=253 time=11.0 ms

64 bytes from 192.0.2.1: icmp_seq=5 ttl=253 time=9.72 ms

--- 192.0.2.1 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4016ms

rtt min/avg/max/mdev = 6.854/8.804/11.072/1.495 ms


If the computer cannot reach the destination via ICMP, if you specified a wait and packet count rather than having the command wait for your Control-C, output similar to the following appears:

PING 192.0.2.15 (192.0.2.15) 56(84) bytes of data.

--- 192.0.2.15 ping statistics ---

5 packets transmitted, 0 received, 100% packet loss, time 5999ms

“100% packet loss” indicates that the host is not reachable.


Otherwise, if you terminate by pressing Control-C (^C), output similar to the following appears:

PING 192.0.2.15 (192.0.2.15) 56(84) bytes of data.

From 192.0.2.2 icmp_seq=31 Destination Host Unreachable

From 192.0.2.2 icmp_seq=30 Destination Host Unreachable

From 192.0.2.2 icmp_seq=29 Destination Host Unreachable

^C

--- 192.0.2.15 ping statistics ---

41 packets transmitted, 0 received, +9 errors, 100% packet loss, time 40108ms

pipe 3

“100% packet loss” and “Destination Host Unreachable” indicates that the host is not reachable.

Testing routes & latency with traceroute

traceroute sends ICMP packets to test each hop along the route. It sends three packets to the destination, and then increases the time to live (TTL) setting by one, and sends another three packets to the destination. As the TTL increases, packets go one hop farther along the route until they reach the destination.

Most traceroute commands display their maximum hop count—the maximum number of steps it will take before declaring the destination unreachable—before they start tracing the route. The TTL setting may result in routers or firewalls along the route timing out due to high latency.

Where ping only tells you if the signal reached its destination and returned successfully, traceroute shows each step of its journey to its destination and how long each step takes. If you specify the destination using a domain name, the traceroute output can also indicate DNS problems, such as an inability to connect to a DNS server.

By default, traceroute uses UDP with destination ports numbered from 33434 to 33534. The traceroute utility usually has an option to specify use of ICMP ECHO_REQUEST (type 8) instead, as used by the Windows tracert utility. If you have a firewall and you want traceroute to work from both machines (Unix-like systems and Windows) you will need to allow both protocols inbound through your firewall (UDP ports 33434 - 33534 and ICMP type 8).

To trace the route to a device from the FortiWeb CLI
  1. Log in to the CLI via either SSH, Telnet, or you can ping from the FortiWeb appliance in the CLI Console widget of the web UI.
  2. Enter the command:
  3. execute traceroute {<destination_ipv4> | <destination_fqdn>}


    where {<destination_ipv4> | <destination_fqdn>} is a choice of either the device’s IP address or its fully qualified domain name (FQDN).

    For example, you might enter:

    execute traceroute www.example.com


    If the appliance has a complete route to the destination, output similar to the following appears:

    traceroute to www.fortinet.com (192.0.2.150), 32 hops max, 84 byte packets

    1 192.0.2.87 0 ms 0 ms 0 ms

    2 192.0.2.221 <static-209-87-254-221.storm.ca> 2 ms 2 ms 2 ms

    3 192.0.2.129 <core-2-g0-1-1104.storm.ca> 2 ms 1 ms 2 ms

    4 192.0.2.161 2 ms 2 ms 3 ms

    5 192.0.2.17 <core2-ottawa23_POS13-1-0.net.bell.ca> 3 ms 3 ms 2 ms

    6 192.0.2.234 <core2-ottawatc_POS5-0-0.net.bell.ca> 20 ms 20 ms 20 ms

    7 192.0.2.58 <core4-toronto21_POS0-12-4-0.net.bell.ca> 24 ms 21 ms 24 ms

    8 192.0.2.154 <bx4-toronto63_so-2-0-0-0.net.bell.ca> 8 ms 9 ms 8 ms

    9 192.0.2.145 <bx2-ashburn_so2-0-0.net.bell.ca> 23 ms 23 ms 23 ms

    10 192.0.2.9 23 ms 22 ms 22 ms

    11 192.0.2.238 <cr2.wswdc.ip.att.net> 100 ms 192.0.2.130 <cr2.wswdc.ip.att.net> 101 ms 102 ms

    12 192.0.2.21 <cr1.cgcil.ip.att.net> 101 ms 100 ms 99 ms

    13 192.0.2.121 <cr1.sffca.ip.att.net> 100 ms 98 ms 100 ms

    14 192.0.2.118 <cr81.sj2ca.ip.att.net> 98 ms 98 ms 100 ms

    15 192.0.2.105 <gar2.sj2ca.ip.att.net> 96 ms 96 ms 96 ms

    16 192.0.2.42 94 ms 94 ms 94 ms

    17 192.0.2.10 88 ms 87 ms 87 ms

    18 192.0.2.130 90 ms 89 ms 90 ms

    19 192.0.2.150 <fortinet.com> 91 ms 89 ms 91 ms

    20 192.0.2.150 <fortinet.com> 91 ms 91 ms 89 ms


    Each line lists the routing hop number, the IP address and FQDN (if any) of that hop, and the 3 response times from that hop. Typically a value of <1ms indicates a local router.

    If the appliance does not have a complete route to the destination, output similar to the following appears:

    traceroute to 192.0.2.1 (192.0.2.1), 32 hops max, 84 byte packets

    1 192.0.2.2 0 ms 0 ms 0 ms

    2 192.0.2.10 0 ms 0 ms 0 ms

    3 * * *

    4 * * *


    The asterisks ( * ) indicate no response from that hop in the network routing. For details, see the FortiWeb CLI Reference:

    HTTPs://docs.fortinet.com/product/fortiweb/

To trace the route to a device from a Microsoft Windows computer
  1. Click the Start (Windows logo) menu to open it.
  2. If the host is running Windows XP, instead, go to Start > Run...

  3. Type cmd then press Enter.
  4. The Windows command line appears.

  5. Enter the command:
  6. tracert {<destination_ipv4> | <destination_fqdn>}

    If the appliance has a complete route to the destination, output similar to the following appears:

    Tracing route to www.fortinet.com [192.0.2.34]

    over a maximum of 30 hops:

    1 <1 ms <1 ms <1 ms 192.0.2.2

    2 2 ms 2 ms 2 ms static-192-0-2-221.storm.ca [192.0.2.221]

    3 2 ms 2 ms 22 ms core-2-g0-1-1104.storm.ca [192.0.2.129]

    4 3 ms 3 ms 2 ms 67.69.228.161

    5 3 ms 2 ms 3 ms core2-ottawa23_POS13-1-0.net.bell.ca [192.0.2.17]

    (Output abbreviated.)

    15 97 ms 97 ms 97 ms gar2.sj2ca.ip.att.net [192.0.2.105]

    16 94 ms 94 ms 94 ms 192.0.2.42

    17 87 ms 87 ms 87 ms 192.0.2.10

    18 89 ms 89 ms 90 ms 192.0.2.130

    19 89 ms 89 ms 90 ms fortinet.com [192.0.2.34]

    20 90 ms 90 ms 91 ms fortinet.com [192.0.2.34]

    Trace complete.


    Each line lists the routing hop number, the 3 response times from that hop, and the IP address and FQDN (if any) of that hop. Typically a value of <1ms indicates a local router.

    If the appliance does not have a complete route to the destination, output similar to the following appears:

    Tracing route to 192.0.2.1 over a maximum of 30 hops

    1 <1 ms <1 ms <1 ms 192.0.2.2

    2 <1 ms <1 ms <1 ms 192.0.2.10

    3 * * * Request timed out.

    4 * * * Request timed out.

    5 ^C


    The asterisks ( * ) and “Request timed out.” indicate no response from that hop in the network routing.

To trace the route to a device from a Linux or Mac OS X computer
  1. Open a command prompt.
  2. Alternatively, on Mac OS X, you can use the Network Utility application.
  3. Enter:
  4. traceroute {<destination_ipv4> | <destination_fqdn>}


    Note: the path to the executable may vary by distribution.

    If the appliance has a complete route to the destination, output similar to the following appears:

    traceroute to www.fortinet.com (192.0.2.34), 30 hops max, 60 byte packets

    1 192.0.2.2 (192.0.2.2) 0.189 ms 0.277 ms 0.226 ms

    2 static-192-0-2-221.storm.ca (192.0.2.221) 2.554 ms 2.549 ms 2.503 ms

    3 core-2-g0-1-1104.storm.ca (192.0.2.129) 2.461 ms 2.516 ms 2.417 ms

    4 192.0.2.161 (192.0.2.161) 3.041 ms 3.007 ms 2.966 ms

    5 core2-ottawa23_POS13-1-0.net.bell.ca (192.0.2.17) 3.004 ms 2.998 ms 2.963 ms

    (Output abbreviated.)

    16 192.0.2.42 (192.0.2.42) 94.379 ms 94.114 ms 94.162 ms

    17 192.0.2.10 (192.0.2.10) 122.879 ms 120.690 ms 119.049 ms

    18 192.0.2.130 (203.78.181.130) 89.705 ms 89.411 ms 89.591 ms

    19 fortinet.com (192.0.2.34) 89.717 ms 89.584 ms 89.568 ms


    Each line lists the routing hop number, the IP address and FQDN (if any) of that hop, and the 3 response times from that hop. Typically a value of <1ms indicates a local router.

    If the appliance does not have a complete route to the destination, output similar to the following appears:

    traceroute to 192.0.2.1 (192.0.2.1), 30 hops max, 60 byte packets

    1 * * *

    2 192.0.2.10 (192.0.2.10) 4.160 ms 4.169 ms 4.144 ms

    3 * * *

    4 * * *^C


    The asterisks ( * ) indicate no response from that hop in the network routing.

    Relatedly, if the computer’s DNS query cannot resolve the host name, output similar to the following appears:

    example.lab: Name or service not known

    Cannot handle "host" cmdline arg `example.lab' on position 1 (argc 1)