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