| Solution |
To troubleshoot and resolve a slow website loading issue with FortiGate involving ICAP server, follow these steps:
- Collect debug logs, sniffer outputs, and forward traffic logs to identify the root cause of the issue.
- Verify the firewall policy configuration and ensure that Application Control is enabled.
- Check for any packet drops or errors in the debug logs and sniffer outputs.
- Test the website loading speed with and without Application Control enabled to isolate the issue.
- If the issue persists, try disabling the traffic shaper and adjusting the bandwidth limits.
- Collect ICAP sniffer and debug logs to investigate any issues with the ICAP server.
- Verify the ICAP server configuration and ensure that it is reachable and responsive.
- If the issue is still not resolved, collect ICAP debugs as follows:
- Capture the output in the text file by following the steps outlined in Technical Tip: Troubleshooting ICAP Profile.
diagnose debug reset
diagnose debug console timestamp enable
diagnose wad debug enable category icap
diagnose wad debug enable category http <----- This command is optional for displaying HTTP debugging details.
diagnose wad debug enable level info
diagnose debug enable
Debug analysis:
wad_http_parse_host : host=google.com
canonicalize : path=/, len=1
wad_url_filter_local_request ... action=allow
wad_url_choose_cate : cate=41 (ftgd)
wad_url_filter_dump_result : type=req_http, action=ftgd-monitor
wad_http_icap_task_start
lb_server=Fortinet ... state=up conn_action=forward
wad_icap_proc ... switch/is_req: 0/1
task end ... good=1 ... processing=1
- Plain HTTP HEAD request to google.com.
-
FTGD categorized it as 41 (exact textual name depends on FTGD database; often 'Search Engines/Portals' or something similar).
-
Web filter action is monitor (no block), and ICAP task starts.
-
WAD selects ICAP server Fortinet (up, forwarding).
-
good=1 indicates the ICAP task completed successfully from WAD’s perspective.
-
For HEAD, there is no body; REQMOD is typically headers-only (Encapsulated with null-body), or ICAP can be skipped depending on profile. Here, ICAP was invoked.
No errors or timeouts are shown for this transaction.
ICAP invocation and connection attempts:
wad_http_icap_task_start
lb_server=Fortinet... state=up ... forward
wad_icap_srv_conn_new ... ireq ... connecting
wad_icap_srv_conn_on_error ... (:0->10.10.10.1:1344): wad icap port cancel/error
icap_http_proc_conn_open : ERROR Fail to open icap port.
-
WAD tries to connect to ICAP via the LB server Fortinet, which maps to 10.10.10.1:1344.
- Immediate connection error is identified -> 'Fail to open icap port'.
- WAD force closes the ICAP connection object.
- This indicates connectivity failure (TCP open failed, or a very fast cancel) toward the ICAP service port.
Troubleshooting steps:
- Verify immediate connectivity from FortiGate (same VDOM as the policy using ICAP).
- Verify ICAP service status on 10.10.10.1. Check logs for connection refusals or crashes.
- FortiGate ICAP profile sanity check by confirming ICAP service URI (server, port and service path) matches the ICAP server.
- If the design involves secure ICAP (ICAP/TLS), ensure that the FortiGate profile is configured accordingly and the server is listening on a TLS port, often it is not 1344.
- If the error is intermittent, check ICAP server connection limits, FDs, and maximum sessions.
- If the issue persists, try rebooting the ICAP server and verifying the website loading speed again.
Following these steps enables identification and resolution of the slow website loading issue with FortiGate.
|
