What is the use of ping command to test a device on the network is reachable to test a hard disk fault?

Check within your organization. You can save time and effort during the troubleshooting process by checking if other FortiWeb administrators experienced a similar problem before.

Connectivity issues

One of your first tests when configuring a new policy should be to determine whether allowed traffic is flowing to your web servers.

• Is there a server policy applied to the web server or servers FortiWeb was installed to protect? If it is operating in Reverse Proxy mode, FortiWeb will not allow any traffic to reach a protected web server unless there is a matching server policy that permits it.
• If your network utilizes secure connections [HTTPS] and there is no traffic flow, is there a problem with your certificate?
• If you run a test attack from a browser aimed at your website, does it show up in the attack log?

To verify, configure FortiWeb to detect the attack, then craft a proof-of-concept that will trigger the attack sensor. For example, to see whether directory traversal attacks are being logged and/or blocked, you could use your web browser to go to:

//www.example.com/login?user=../../../../

Under normal circumstances, you should see a new attack log entry in the attack log console widget of the system dashboard. For details, see Attack Log widget.

See also

Checking hardware connections

If there is no traffic flowing from the FortiWeb appliance, it may be a hardware problem.

To check hardware connections

• Ensure the network cables are properly plugged in to the interfaces on the FortiWeb appliance.
• Ensure there are connection lights for the network cables on the appliance.
• Change the cable if the cable or its connector are damaged or you are unsure about the cable’s type or quality.
• Connect the FortiWeb appliance to different hardware to see if that makes a difference.

• In the web UI, go to Status > Network > Interface and ensure that the link status is up for the interface.

  If the status is down [down arrow on red circle], click Bring Up next to it in the Status column.

  You can also enable an interface in CLI, for example:

  config system interface

  edit port2

  set status up

  end

If any of these checks solve the problem, it was a hardware connection issue. You should still perform some basic software tests to ensure complete connectivity.

If the hardware connections are correct and the appliance is powered on but you cannot connect using the CLI or web UI, you may be experiencing bootup problems. See Bootup issues.

Examining the ARP table

When you have poor connectivity, another good place to look for information is the address resolution protocol [ARP] table. A functioning ARP is especially important in high-availability configurations.

To check the ARP table in the CLI, enter:

diagnose network arp list

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:

//docs.fortinet.com/document/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.

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.

2. 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.

A dialog appears.

3. Enable PING.

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 traceroute0 or traceroute1 that send such traffic.

4. If Trusted Host #1, Trusted Host #2, and Trusted Host #3 have been restricted, verify that they include your computer or device’s IP address. Otherwise FortiWeb will not respond.
5. Click OK.

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.

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

2. 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.
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.

3. Use the traceroute5 or traceroute command on both the client and the server [depending on their operating systems] to locate the point of failure along the route.

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 blacklisting, 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.

4. 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 traceroute7 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 config router setting1 [“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 config router setting8 command. For details, see the FortiWeb CLI Reference:

//docs.fortinet.com/document/fortiweb/

3. Enter the command:

execute ping

where config router setting9 is the IP address of the device that you want to verify that the appliance can connect to, such as ping0.

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:

//docs.fortinet.com/document/fortiweb/

To ping a device from a Microsoft Windows computer

1. Click the Start [Windows logo] menu to open it.

If the host is running Windows XP, instead, go to Start > Run...

2. Type ping1 then press Enter.

   The Windows command line appears.

3. Enter the command:

   ping

   where:

   • config router setting9 is the IP address of the device that you want to verify that the computer can connect to, such as ping3.
   • are zero or more options, such as:
     • ping4—Send packets until you press Control-C.
     • ping5—Resolve IP addresses to domain names where possible.
     • ping6x—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.
Alternatively, on Mac OS X, you can use the Network Utility application.
2. Enter the following command:

ping

where:

• config router setting9 is the IP address of the device that you want to verify that the computer can connect to, such as ping3.
• are zero or more options, such as:
  • ping9y—Wait y seconds for config router setting1.
  • traceroute1x—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 traceroute3.

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 traceroute4.

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 [traceroute5], 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 traceroute5 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:

execute traceroute { |}

where { |} 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.2212 ms 2 ms 2 ms

3 192.0.2.1292 ms 1 ms 2 ms

4 192.0.2.161 2 ms 2 ms 3 ms

5 192.0.2.173 ms 3 ms 2 ms

6 192.0.2.23420 ms 20 ms 20 ms

7 192.0.2.5824 ms 21 ms 24 ms

8 192.0.2.1548 ms 9 ms 8 ms

9 192.0.2.14523 ms 23 ms 23 ms

10 192.0.2.9 23 ms 22 ms 22 ms

11 192.0.2.238100 ms 192.0.2.130101 ms 102 ms

12 192.0.2.21101 ms 100 ms 99 ms

13 192.0.2.121100 ms 98 ms 100 ms

14 192.0.2.11898 ms 98 ms 100 ms

15 192.0.2.10596 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.15091 ms 89 ms 91 ms

20 192.0.2.15091 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 ECHO_REPSPONSE5 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:

//docs.fortinet.com/document/fortiweb/

To trace the route to a device from a Microsoft Windows computer

1. Click the Start [Windows logo] menu to open it.

If the host is running Windows XP, instead, go to Start > Run...

2. Type ping1 then press Enter.

The Windows command line appears.

3. Enter the command:

traceroute5{ |}

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 Status > Status and examine the graphs in the Policy Summary widget.

4. Examine traffic history in the traffic log. Go to Logs&Report > Log Access > Traffic.

Preparing for attacks

A prolonged denial of service [DoS] or brute-force login attack [to name just a few] can bring your web servers to a standstill, if your FortiWeb appliance is not configured for it.

To fight DoS attacks, see DoS prevention.

In the FortiWeb appliance's web UI, you can watch for attacks in two ways:

• Monitor current HTTP traffic on the dashboard. Go to System > Status > Status and examine the attack event history graph in the Policy Summary widget.
• Examine attack history in the traffic log. Go to Logs&Report > Log Access > Attack.

Before attacks occur, use the FortiWeb appliance's rich feature set to configure attack defenses.

Login issues

If the person cannot access the login page at all, it is usually actually a connectivity issue [see Ping & traceroute and Configuring the network settings] unless all accounts are configured to accept logins only from specific IP addresses [see Trusted Host #1].

If an administrator can connect, but cannot log in, even though providing the correct account name and password, and is receiving this error message:

Too many bad login attemptsor reached max number of logins. Please try again in a few minutes. Login aborted.

single administrator mode may have been enabled. For details, see How to use the web UI.

If the person has lost or forgotten his or her password, the ECHO_REQUEST9 account can reset other accounts’ passwords. For details, see Changing an administrator’s password.

Checking user authentication policies

In FortiWeb, users and organized into groups. Groups are part of authentication policies. If several users have authentication problems, it is possible someone changed authentication policy or user group memberships. If a user is legitimately having an authentication policy, you need to find out where the problem lies.

To troubleshoot user access
1. In the web UI, go to User > User Group > User Group and examine each group to locate the name of the problem user.
2. Note the user group to which the affected users belong, especially if multiple affected users are part of one group. If the user is not a group member, there is no access.
3. Go to Application Delivery > Authentication and select the Authentication Rule tab to determine which rule contains the problem user group. If the user group is not part of a rule, there is no access.
4. Go to Application Delivery > Authentication and select the Authentication Policy tab to locate the policy that contains the rule governing the problem user group. If the rule is not part of a policy, there is no access.
5. Go to Policy > Web Protection Profile and select the Inline Protection Profile tab to determine which profile contains the related authentication policy. If the policy is not part of a profile, there is no access.
6. Make sure that inline protection profile is included in the server policy that applies to the server the user is trying to access. If the profile is not part of the server policy, there is no access.

Authentication involves user groups, authentication rules and policy, inline protection policy, and finally, server policy. If a user is not in a user group used in the policy for a specific server, the user will have no access.

When an administrator account cannot log in from a specific IP

If an administrator is entering his or her correct account name and password, but cannot log in from some or all computers, examine that account’s trusted host definitions [see Trusted Host #1]. It should include all locations where that person is allowed to log in, such as your office, but should not be too broad.

Remote authentication query failures

If your network administrators’ or other accounts reside on an external server [e.g. Active Directory or RADIUS], first switch the account to be locally defined on the FortiWeb appliance. If the local account fails, correct connectivity between the client and appliance [see Connectivity issues]. If the local account succeeds, troubleshoot connectivity between the appliance and your authentication server. If routing exists but authentication still fails, you can verify correct vendor-specific attributes and other protocol-specific fields by running a packet trace [see Packet capture].

Resetting passwords

If you forget the password, or want to change an account’s password, the ECHO_REQUEST9 administrator can reset the password.

If you forget the password of the ECHO_REQUEST9 administrator, you can either:

• Login via other account with ping2 permission only by CLI console.
• Remove the admin password from the backup configuration file by web UI.
To reset an account’s password
1. Log in as the ECHO_REQUEST9 administrator account to web UI.
2. Go to System > Admin > Administrators.
3. Click the row to select the account whose password you want to change.
4. Click Change Password.
5. In the New Password and Confirm Password fields, type the new password.
6. Click OK.

   The new password takes effect the next time that account logs in.

To reset the ECHO_REQUEST9 account’s password

Option 1:

1. Connect to the CLI console with an account of ping2 permission.
2. Run the following commands:

   config system admin

   edit admin

   set password a

   end

Option 2:

1. Login to the web UI with an account of ping2 permission.
2. Go to Maintenance > Backup & Restore > Backup.
3. Click Backup to download the backup file.
4. Decompress the .zip file, and open the fwb_system.conf file with the editor. You are recommended to use Notepad++.
5. Locate the ping7 command lines, remove the ping8 line as below, and save the file.

   You can use alerts to notify you when FortiWeb has almost consumed its hard disk space. For details, see SNMP traps & queries.

   You can also configure FortiWeb to overwrite old logs rather than stopping logging when the disk is full. For details, see When log disk is full.

   Keep in mind, however, that this may not prevent full disk problems for other features. To free disk space, delete files such as old reports that you no longer need.

   If a full disk is not the problem, examine the configuration to determine if an administrator has disabled those features that store data.

   If neither of those indicate the cause of the problem, verify that the disk’s file system has not been mounted in read-only mode, which can occur if the hard disk is experiencing problems with its write capabilities. For details, see Hard disk corruption or failure.

   Bootup issues

   While FortiWeb is booting up, hardware and firmware components must be present and functional, or startup will fail. Depending on the degree of failure, FortiWeb may appear to be partially functional. You may notice that you cannot connect at all. If you can connect, you may notice that features such as reports and anti-defacement do not work. If you have enabled logging to an external location such as a Syslog server or FortiAnalyzer, or to memory, you should notice this log message:

   log disk not mounted

   Depending on the cause of failure, you may be able to fix the problem.

   Hard disk corruption or failure

   FortiWeb appliances usually have multiple disks. FortiWeb stores its firmware [operating system] and configuration files in a flash disk, but most models of FortiWeb also have an internal hard disk or RAID that is used to store non-configuration/firmware data such as logs, reports, and website backups for anti-defacement. During startup, after FortiWeb loads its boot loader, FortiWeb will attempt to mount its data disk. If this fails due to errors, you will have the opportunity to attempt to recover the disk.

   To determine if one of FortiWeb’s internal disks may either:

   • Have become corrupted
   • Have experienced mechanical failure

   view the event log. If the data disk failed to mount, you should see this log message:

   date=2012-09-27 time=07:49:07 log_id=00020006 msg_id=000000000002 type=event subtype="system" pri=alert device_id=FV-1KC3R11700136 timezone="[GMT-5:00]Eastern Time[US & Canada]" msg="log disk is not mounted"

   Connect to FortiWeb’s CLI via local console, then supply power. After the boot loader starts, you should see this prompt:

   Press [enter] key for disk integrity verification.

   Pressing the Enter key will cause FortiWeb to check the hard disk’s file system to attempt to resolve any problems discovered with that disk’s file system, and to determine if the disk can be mounted [mounted disks should appear in the internal list of mounted file systems, ping9]. During the check, FortiWeb will describe any problems that it finds, and the results of disk recovery attempts, such as:

   ext2fs_check_if_mount: Can’t detect if filesystem is mounted due to missing mtab file while determining where /dev/sda1 is mounted.

   /dev/sda1: recovering journal

   /dev/sda1: clean, 56/61054976 files, 3885759/244190638 blocks

   If the problem occurs while FortiWeb is still running [or after an initial reboot and attempt to repair the file system], in the CLI, enter:

   diagnose hardware harddisk list

   to display the number and names of mounted file systems.

   For example, on a FortiWeb 1000C with a single properly functioning internal hard disk plus its internal flash disk, this command should show two file systems:

   name size[M]

   sda 1000204.89

   sdb 1971.32

   where traceroute0, the larger file system, is from the hard disk used to store non-configuration/firmware data.

   If that command does not list the data disk’s file system, FortiWeb did not successfully mount it. Try to reboot and run the file system check.

   If the data disk’s file system is listed and appears to be the correct size, FortiWeb could mount it. However, there still could be other problems preventing the file system from functioning, such as being mounted in read-only mode, which would prevent new logs and other data from being recorded. To determine this, enter:

   diagnose hardware logdisk info

   to display the count, capacity, RAID status/level, partition numbers, and read-write/read-only mount status.

   For example, on a FortiWeb-1000C with a single properly functioning data disk, this command should show:

   disk number: 1

   disk[0] size: 976.76GB

   raid level: raid1

   partition number: 1

   mount status: read-write

   To prevent file system corruption in the future, and to prevent possible physical damage, always make sure to shut down FortiWeb’s operating system before disconnecting the power.

   You can also display the status of each individual disk in the RAID array:

   FortiWeb # diag hardware raid list

   disk-number size[M] level

   0[OK],1[OK], 1877274 raid1

   If the file system could not be fixed by the file system check, it may be physically damaged or components may have worn out prematurely. Most commonly, this is caused by either:

   • Failing to shut down FortiWeb’s operating system before disconnecting the power [e.g. someone pulled the power plug while FortiWeb was running]
   • Logging misconfiguration [e.g. logging very frequent logs like traffic logs or debug logs for an extended period of time to the local hard drive]

   For hardware replacement, contact Fortinet Customer Service & Support:

   //support.fortinet.com

   Power supply failure

   If you have supplied power, but the power indicator LEDs are not lit and the hardware has not started, the power supply may have failed. Contact Fortinet Customer Service & Support:

   //support.fortinet.com

   After powering on, if the power indicator LEDs are lit but a few minutes have passed and you still cannot connect to the FortiWeb appliance through the network using CLI or the web UI, you can either:

   • Verify that FortiWeb can successfully complete bootup.
   Always halt the FortiWeb OS before disconnecting the power. Power disruption while the OS is running can cause damage to the disks and/or software.

   To verify bootup, connect your computer directly to FortiWeb’s local console port, then on your computer, open a terminal emulator such as PuTTY [//www.chiark.greenend.org.uk/~sgtatham/putty/download.html]. Configure it to log all printable console output to a file so that you have a copy of the console's output messages in case you need to send it to Fortinet Customer Service & Support:

   //support.fortinet.com

   Once connected, power cycle the appliance and observe the FortiWeb’s output to your terminal emulator. You will be looking for some specific diagnostic indicators.

   1. Are there console messages but text is garbled on the screen? If yes, verify your terminal emulator’s settings are correct for your hardware. Typically, however, these are baud rate 9600, data bits 8, parity none, stop bits 1.
   2. Does the hardware successfully complete the hardware power on self test [POST] and BIOS memory tests?

   If not, you may need to replace the hardware. For assistance, contact Fortinet Customer Service & Support:

   //support.fortinet.com

   3. Does the boot loader start? You should see a message such as:

   traceroute1

   FortiWebtraceroute2

   traceroute3

   traceroute4

   traceroute5

   traceroute6

   traceroute7

   If the boot loader does not start, you may need to restore it. For assistance, contact Fortinet Customer Service & Support:

   //support.fortinet.com

   4. When pressing a key during the boot loader, do you see the following boot loader options?

   traceroute8

   traceroute9

   ECHO_REQUEST0

   If the boot loader does not start, you may need to restore it. For assistance, contact Fortinet Customer Service & Support:

   //support.fortinet.com

   5. Can the boot loader read the image of the OS software in the selected boot partition [primary or backup/secondary, depending on your selection in the boot loader]? You should see a message such as the following:

   ECHO_REQUEST1

   ECHO_REQUEST2

   ECHO_REQUEST3

   If not, the image may be corrupted. Reboot and use the boot loader to switch to the other partition, if any. For details, see Booting from the alternate partition.

   If this is not possible, you can restore the firmware. If the firmware cannot be successfully restored, format the boot partition, and try again. For details, see Restoring firmware [“clean install”].

   If you still cannot restore the firmware, there could be either a boot loader or disk issue. Contact Fortinet Customer Service & Support:

   //support.fortinet.com

   6. Does the login prompt appear? You should see a prompt like this:

   FortiWebECHO_REQUEST4

   If not, or if the login prompt is interrupted by error messages, restore the OS software. If you recently upgraded the firmware, try downgrading by restoring the previously installed, last known good, version. For details, see Restoring firmware [“clean install”].

   If restoring the firmware does not solve the problem, there could be a data or boot disk issue. Contact Fortinet Customer Service & Support:

   //support.fortinet.com

   If you can see and use the login prompt on the local console, but cannot successfully establish a session through the network [web UI, SSH or Telnet], first examine a backup copy of the configuration file to verify that it is not caused by a misconfiguration. The network interface and administrator accounts must be configured to allow your connection and login attempt. For details, see Configuring the network settings and Trusted Host #1.

   If the configuration appears correct, but no network connections are successful, first try restoring the firmware to rule out corrupted data that could be causing problems. For details, see Restoring firmware [“clean install”]. You can also use this command to verify that resource exhaustion is not the problem:

   diagnose system top delay 5

   The process system usage statistics continues to refresh and display in the CLI until you press ECHO_REQUEST8[quit].

   Issues forwarding non-HTTP/HTTPS traffic

   If FortiWeb is operating in Reverse Proxy mode, by default, it does not forward non HTTP/HTTPS protocols to protected servers.

   What is the use of ping command to test a device on the network is reachable?

   Ping is a network administration utility or tool used to test connectivity on an Internet Protocol [IP] network. It also measures the latency or delay between two computers. To test network connectivity with ping: Open the Command Prompt or Terminal.

   What is the use of the ping command?

   ping is the primary TCP/IP command used to troubleshoot connectivity, reachability, and name resolution. Used without parameters, this command displays Help content. You can also use this command to test both the computer name and the IP address of the computer.