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
- Go to Network > Interface.
- In the row for the network interface which you want to respond to ICMP type 8 (
ECHO_REQUEST
) forping
and UDP fortraceroute
, click Edit. - Enable PING.
- 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.
- Click OK.
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.
A dialog appears.
Disabling PING only prevents FortiWeb from receiving ICMP type 8 ( It does not disable FortiWeb CLI commands such as |
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
- Attempt to connect through the FortiWeb appliance, from a client to a protected web server, via HTTP and/or HTTPS.
- 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. - Use the
tracert
ortraceroute
command on both the client and the server (depending on their operating systems) to locate the point of failure along the route. - For application-layer problems, on the FortiWeb, examine the:
If the connectivity test fails, continue to the next step.
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.
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.
- 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
- 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.
- If you want to adjust the behavior of execute ping, first use the
execute ping options
command. For details, see the FortiWeb CLI Reference: - Enter the command:
HTTPS://docs.fortinet.com/product/fortiweb/
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:
To ping a device from a Microsoft Windows computer
- Click the Start (Windows logo) menu to open it.
- Type
cmd
then press Enter.The Windows command line appears.
- 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 as192.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.
If the host is running Windows XP, instead, go to Start > Run...
To ping a device from a Linux or Mac OS X computer
- Open a command prompt.
- Enter the following command:
Alternatively, on Mac OS X, you can use the Network Utility application. |
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 as192.0.2.1
.- <options_str> are zero or more options, such as:
-W
y—Wait y seconds forECHO_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
- 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.
- Enter the command:
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:
To trace the route to a device from a Microsoft Windows computer
- Click the Start (Windows logo) menu to open it.
- Type
cmd
then press Enter. - Enter the command:
If the host is running Windows XP, instead, go to Start > Run...
The Windows command line appears.
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
- Open a command prompt.
- Enter:
Alternatively, on Mac OS X, you can use the Network Utility application. |
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)