Web Cache Communication Protocol (WCCP) is widely used in enterprise networks to redirect selected traffic from routers and firewalls to dedicated proxy or caching servers. On a FortiGate firewall, a correctly configured WCCP setup ensures that traffic is transparently redirected, improving inspection depth, content filtering, or caching efficiency. However, configuration alone is not proof of functionality. Verification is essential to ensure that redirection is actually taking place and that the service group is stable and operational.
TL;DR: To verify WCCP on a FortiGate firewall, confirm configuration settings, check service group status, and monitor real-time session handling using CLI diagnostic commands. Review logs to ensure traffic is being redirected and confirm that the WCCP peer is properly registered. If issues arise, validate network reachability, service IDs, and return path routing. Consistent monitoring of debug output and counters is key to troubleshooting.
Understanding How WCCP Works on FortiGate
Before verifying functionality, it is important to understand how WCCP operates within a FortiGate environment. WCCP enables traffic redirection by establishing communication between the firewall and a caching or proxy server. The firewall uses defined service groups to determine what traffic is eligible for redirection.
Key components include:
- Service Group ID – Identifies the type of traffic being redirected.
- WCCP Router (FortiGate) – Redirects traffic according to policy and service definition.
- WCCP Client (Cache or Proxy Server) – Registers with the firewall and receives redirected traffic.
- Assignment Method – Determines how traffic is distributed (hash or mask).
Verification focuses on ensuring that these elements are synchronized and actively exchanging control messages.
Step 1: Verify WCCP Configuration
The first step is to confirm that the configuration is correct. From the FortiGate CLI, use the following command:
show system wccp
This will display configured service groups, interfaces, and associated parameters.
Carefully validate:
- Correct service ID
- Proper router ID
- Assigned interfaces
- Associated forwarding method (GRE or L2)
- Security policies allowing redirected traffic
If configuration discrepancies appear here, WCCP may partially function or fail entirely.
Step 2: Check WCCP Service Status
After verifying configuration, confirm registration and connectivity status. Use:
diagnose sys wccp status
This command provides crucial visibility, including:
- Registered cache engines
- Service group state
- Assignment method details
- Router and client IP addresses
A healthy output typically shows:
- Client registered
- Service group active
- No registration errors
If the client is not listed, the cache server may not be communicating with the firewall. Confirm routing and ensure that UDP port 2048 (WCCP control traffic) is not blocked.
Step 3: Monitor Real-Time Debug Output
For deeper inspection, enable debugging. This is especially useful if the service group appears configured but traffic is not visibly redirected.
diagnose debug reset diagnose debug enable diagnose debug application wccp -1
This command enables verbose WCCP debugging.
Look for:
- Registration requests from the cache engine
- I see you messages (keepalives)
- Assignment messages
- Error or rejection messages
Common indicators of issues include:
- Service ID mismatch
- Version incompatibility
- Security policy blocking control packets
After testing, disable debugging to avoid performance impact:
diagnose debug disable
Note: Debug sessions should be conducted during maintenance windows when possible, as verbose logging can consume system resources.
Step 4: Validate Session Redirection
A service group may appear active, yet traffic might not actually be redirected. To confirm live traffic redirection, inspect firewall sessions:
diagnose sys session list
Search for sessions that match the defined WCCP service criteria (for example, HTTP traffic if service ID 80 is used).
Verify:
- Source and destination IP addresses
- Session state
- NAT behavior
- Ingress and egress interfaces
When functioning correctly, redirected sessions should show altered forwarding consistent with the WCCP cache engine’s address.
Step 5: Review FortiGate Logs
FortiGate traffic logs provide another layer of confirmation. In the GUI, navigate to:
Log & Report → Forward Traffic
Filter by:
- Service (for example HTTP or HTTPS)
- Destination IP
- Policy ID
Look for patterns where traffic appears first directed toward the firewall and then sent to the cache engine IP.
If logs show direct outbound flows without redirection, verify that:
- The correct firewall policy allows WCCP processing
- Traffic matches the defined service group
- Asymmetric routing is not bypassing the firewall
Common WCCP Problems and Solutions
Even correctly configured environments may encounter operational issues. Below are common problems and targeted troubleshooting steps.
1. Cache Engine Not Registering
Symptoms:
- No clients in diagnose sys wccp status
- No registration messages in debug output
Possible Causes:
- Routing issue between firewall and cache
- UDP 2048 blocked
- Mismatched service IDs
- Incorrect password (if authentication is configured)
2. Traffic Not Redirected
Symptoms:
- Client successfully registered
- No visible traffic on proxy
Actions:
- Confirm policy order on FortiGate
- Validate that traffic matches port/service definition
- Check whether SSL inspection conflicts with WCCP
- Examine return routing path for asymmetry
Asymmetric routing is particularly disruptive. If return traffic bypasses the firewall, sessions may fail or appear incomplete.
3. Intermittent Drops or High Latency
Symptoms:
- Frequent re-registrations in debug logs
- User-reported slow browsing
Possible Causes:
- Unstable WAN link
- MTU mismatch with GRE encapsulation
- Overloaded proxy server
When using GRE forwarding, ensure MTU adjustments account for encapsulation overhead.
Advanced Verification: Packet Sniffing
If logs and debug outputs are inconclusive, use a packet sniffer directly on the FortiGate:
diagnose sniffer packet any "host <cache-ip> and port 2048" 4
This confirms whether WCCP control packets are exchanged between devices.
Additionally, sniff data traffic flowing to the cache engine to confirm redirection:
diagnose sniffer packet any "host <cache-ip>" 4
Look for sustained bidirectional communication. Unidirectional flows indicate firewall policy or routing issues.
Best Practices for Reliable WCCP Operation
Consistent verification is easier when best practices are followed:
- Use static routing between firewall and cache engine.
- Keep service IDs documented and standardized.
- Monitor cache server health separately.
- Avoid complex policy overlaps that may interfere with redirection.
- Regularly review debug logs during maintenance windows.
It is also advisable to test WCCP functionality after firmware upgrades. Changes in FortiOS versions may impact debugging syntax or service group behavior.
Verification Checklist
For operational teams, the following checklist provides a structured approach:
- Confirm configuration using show system wccp.
- Check status with diagnose sys wccp status.
- Validate live control communication using debug commands.
- Inspect session table for redirected flows.
- Review traffic logs for cache engine routing.
- Perform packet capture if inconsistencies persist.
This systematic process eliminates guesswork and ensures that conclusions are based on observable packet flow and system state.
Conclusion
Verifying WCCP functionality on a FortiGate firewall requires more than simply confirming configuration lines. A professional validation approach combines configuration checks, real-time status commands, debug output analysis, session inspection, and log review. When necessary, packet sniffing provides final proof of proper control and data plane operation.
A stable WCCP environment demonstrates consistent registration, visible service group stability, and confirmed traffic redirection in both logs and session tables. By applying structured troubleshooting and maintaining proper routing symmetry, administrators can ensure that WCCP operates reliably and securely within enterprise networks.
In environments where traffic inspection and optimization are mission-critical, regular WCCP verification is not optional—it is operationally essential.