Solutions by issue type

Recommended solutions vary by the type of issue.

Connectivity issues
Resource issues
Login issues
Data storage issues
Bootup issues

Fortinet also provides these resources:

FortiWeb Release Notes (http://docs.fortinet.com/fortiweb/release-information)
Technical documentation (http://docs.fortinet.com/fortiweb/admin-guides)
Knowledge base (http://kb.fortinet.com)
Forums (http://support.fortinet.com/forum)
Online tutorials and training materials (http://training.fortinet.com)

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:

http://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.

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:

https://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

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.

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.

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 execute ping or execute traceroute that send such traffic.

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

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.

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.

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.

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.

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

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:

https://docs.fortinet.com/document/fortiweb/

Enter the command:

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

--- 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/document/fortiweb/

To ping a device from a Microsoft Windows computer

Click the Start (Windows logo) menu to open it.

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

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

Open a command prompt.

Alternatively, on Mac OS X, you can use the Network Utility application.

Enter the following 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:
- -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

--- 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:

https://docs.fortinet.com/document/fortiweb/

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

Click the Start (Windows logo) menu to open it.

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

Type cmd then press Enter.

The Windows command line appears.

Enter the command:

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.

Alternatively, on Mac OS X, you can use the Network Utility application.

Enter:

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)

Examining the routing table

When a route does not exist, or when hops have high latency, examine the routing table. The routing table is where the FortiWeb appliance caches recently used routes.

If a route is cached in the routing table, it saves time and resources that would otherwise be required for a route lookup. If the routing table is full and a new route must be added, the oldest, least-used route is deleted to make room.

To check the routing table in the CLI, enter:

diagnose network route list

Checking port assignments

If you are attempting to connect to FortiWeb on a given network port, and the connection is expected to occur on a different port number, the attempt will fail. For a list of ports used by FortiWeb, see Appendix A: Port numbers. For ports used by your own HTTP network services, see Defining your network services.

Performing a packet trace

When troubleshooting malformed packet or protocol errors, it helps to look inside the protocol headers of packets to determine if they are traveling along the route you expect, and with the flags and other options you expect. For details, see Packet capture.

If you configure virtual servers on your FortiWeb appliance, packets’ destination IP addresses will be those IP addresses, not the physical IP addresses (i.e., the IP address of port1, etc.). An ARP update is sent out when a virtual IP address is configured.

If the packet trace shows that packets are arriving at your FortiWeb appliance’s interfaces but no HTTP/HTTPS packets egress, check that:

Physical links are firmly connected, with no loose wires
Network interfaces/bridges are brought up (see Configuring the network interfaces)
Link aggregation peers, if any, are up (see Link aggregation)
VLAN IDs, if any, match (see Adding VLAN subinterfaces)
Virtual servers or V-zones exist, and are enabled (see Configuring a bridge (V-zone) and Configuring virtual servers on your FortiWeb)
Matching policies exist, and are enabled (see Configuring basic policies)
If using HTTPS, valid server/CA certificates exist (see How to offload or inspect HTTPS)
IP-layer, and HTTP-layer routes, if necessary, match (see Adding a gateway and Routing based on HTTP content)
Web servers are responsive, if server health checks are configured and enabled (see Configuring server up/down checks)
Load balancers, if any, are defined (see Defining your proxies, clients, & X-headers)
Clients are not blacklisted (see Monitoring currently blocked IPs)

For Offline Protection mode, it is usually normal if HTTP/HTTPS packets do not egress. The nature of this deployment style is to listen only, except to reset the TCP connection if FortiWeb detects traffic in violation.

If the packet is accepted by the policy but appears to be dropped during processing, see Debugging the packet processing flow.

Debugging the packet processing flow

If you have determined that network traffic is not entering and leaving the FortiWeb appliance as expected, or not flowing through policies and scans as expected, you can debug the packet flow using the CLI.

For example, the following commands enable debug logs and the logs timestamp, and set other parameters for debug logging:

diagnose debug enable

diagnose debug console timestamp enable

diagnose debug application proxy 7

diagnose debug flow show module-process-detail

diagnose debug flow trace start

diagnose debug flow filter server-ip 192.0.2.20

For detailed information on the diagnose debug commands, see the FortiWeb CLI Reference:

https://docs.fortinet.com/document/fortiweb/

Checking the SSL/TLS handshake & encryption

If the client is attempting to make an HTTPS connection, but the attempt fails after the connection has been initiated, during negotiation, the problem may be with SSL/TLS. Symptoms may include error messages such as:

ssl_error_no_cypher_overlap
(Mozilla Firefox 9.0.1)
Error 113 (net::ERROR_SSL_VERSION_OR_CIPHER_MISMATCH): Unknown error.
(Google Chrome 16.0.912.75 m)

Expected SSL/TLS behavior varies by SSL inspection vs. SSL offloading. For details, see Offloading vs. inspection.

SSL offloading—Reverse Proxy mode only. For details, see Supported features in each operation mode.
The handshake is between the client and FortiWeb. If the connection cannot be established, verify that the browser supports one of the key exchanges, encryption algorithms, and authentication (hashes) offered by FortiWeb. For details, see Supported cipher suites & protocol versions.

SSL inspection—True Transparent Proxy, Offline Protection, and Transparent Inspection modes only.
The handshake is between the client and the web server. If the connection cannot be established, verify that the browser supports one of the key exchanges, encryption algorithms, and authentication (hashes) suggested by the web server. Server-side, you must also verify that your web server supports enough cipher suites that all required clients can connect.

Google Chrome will prefer an anonymous Diffie-Hellman key exchange. This has the property of perfect forward secrecy, which makes SSL inspection theoretically impossible. To guarantee that this is not used to hide attacks from FortiWeb, you must disable it on your web server. On Apache, you would add !ADH to the SSLCipherSuite configuration line. For example:

SSLCipherSuite ALL:!ADH:!EXPORT:!SSLv2:RC4+RSA:+HIGH:+MEDIUM:+LOW

If you are not sure which cipher suites are currently supported, you can use SSL tools such as OpenSSL (http://openssl.org) to discover support. For example, you could use this client-side command to know whether the web server or FortiWeb supports strong (HIGH) encryption:

openssl s_client -connect example.com:443 -cipher HIGH

or supports deprecated or old versions such as SSL 2.0:

openssl s_client -ssl2 -connect example.com:443

If your web servers are required to comply with PCI DSS, you should make sure that your web servers do not allow weak encryption. For example, if your web servers accept SSL 2.0 or MD5 hashes, you may fail your PCI DSS audit.

Resource issues

This section includes troubleshooting questions related to sluggish or stalled performance.

Is a process consuming too much system resources?

See Killing system-intensive processes.
Is a server under attack?

See Preparing for attacks.
Has there been a sustained spike in HTTP traffic related to a specific policy?

See Monitoring traffic load.

Killing system-intensive processes

Use the CLI to view the per-CPU/core process load level and a list of the most system-intensive processes. This may show processes that are consuming resources unusually. For example:

diagnose system top 10

The above command generates a report of processes every 10 seconds. The report provides the process names, their process ID (pid), status, CPU usage, and memory usage.

The report continues to refresh and display in the CLI until you press q (quit).

Once you locate an offending PID, you can terminate it:

diagnose system kill 9 <pid_int>

To determine if high load is frequently a problem, you can display the average load level by using these CLI commands:

get system performance

diagnose system load

For details, see the FortiWeb CLI Reference:

https://docs.fortinet.com/document/fortiweb/

If the issue recurs, and corresponds with a signature or configuration change, you may need to optimize regular expressions to prevent the issue from recurring. For details, see Debugging the packet processing flow and Regular expression performance tips.

Monitoring traffic load

Heavy traffic loads can cause sustained high CPU or RAM usage. If this is unusual, no action may be required, unless you are being subject to a DoS attack. Sustained heavy traffic load may indicate that you need a more powerful model of FortiWeb.

In the FortiWeb appliance's web UI, you can view traffic load two ways:

Monitor current HTTP traffic on the dashboard. Go to System > Status > Status and examine the graphs in the Policy Summary widget.
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 admin 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

In the web UI, go to User > User Group > User Group and examine each group to locate the name of the problem user.
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.
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.
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.
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.
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 admin administrator can reset the password.

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

Login via other account with prof_admin permission only by CLI console.
Remove the admin password from the backup configuration file by web UI.

To reset an account’s password

Log in as the admin administrator account to web UI.
Go to System > Admin > Administrators.
Click the row to select the account whose password you want to change.
Click Change Password.
In the New Password and Confirm Password fields, type the new password.
Click OK.
The new password takes effect the next time that account logs in.

To reset the `admin` account’s password

Option 1:

Connect to the CLI console with an account of prof_admin permission.
Run the following commands:

config system admin

edit admin

set password a

end

Option 2:

Login to the web UI with an account of prof_admin permission.
Go to Maintenance > Backup & Restore > Backup.
Click Backup to download the backup file.
Decompress the .zip file, and open the fwb_system.conf file with the editor. You are recommended to use Notepad++.
Locate the config system admin command lines, remove the set password XXX line as below, and save the file.
Go to Maintenance > Backup & Restore > Restore.
Click Choose File to upload the updated backup file.
Click Restore.

Data storage issues

If FortiWeb cannot locally store any data such as logs, reports, and website backups for anti-defacement, it might have a damaged or corrupted hard disk. For fixes, see Hard disk corruption or failure.

If FortiWeb has been storing data but has suddenly stopped, first verify that FortiWeb has not used all of its local storage capacity by entering this CLI command:

diagnose system mount list

to display disk usage for all mounted file systems, such as:

Filesystem 1k-blocks Used Available Use% Mounted on

/dev/ram0 61973 31207 30766 50% /

none 262144 736 261408 0% /tmp

none 262144 0 262144 0% /dev/shm

/dev/sdb2 38733 25119 11614 68% /data

/dev/sda1 153785572 187068 145783964 0% /var/log

/dev/sdb3 836612 16584 777528 2% /home

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, /etc/mtab). 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 sda, 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:

https://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:

https://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:

Restore the firmware. For details, see Restoring firmware (“clean install”).

This usually solves most typically occurring issues.

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 (http://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:

https://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.

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

https://support.fortinet.com

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

FortiBootLoader

FortiWeb-1000C (17:52-09.08.2011)

Ver:00010018

Serial number:FV-1KC3R11700094

Total RAM: 3072MB

Boot up, boot device capacity: 1880MB.

Press any key to display configuration menu...

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

https://support.fortinet.com

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

[G]: Get firmware image from TFTP server. [F]: Format boot device. [B]: Boot with backup firmware and set as default. [Q]: Quit menu and continue to boot with default firmware. [H]: Display this list of options. Enter G,F,B,Q,or H: Please connect TFTP server to Ethernet port "1".

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

https://support.fortinet.com

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:

Reading boot image 2479460 bytes.

Initializing FortiWeb...?

System is started.

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:

https://support.fortinet.com

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

FortiWeb login:

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:

https://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 q (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.

However, you can use the following command to enable IP-based forwarding (routing):

config router setting

set ip-forward {enable | disable}

end