So you’ve enabled WCCP on your FortiGate firewall. High five! But now comes the big question: Is it actually working? Don’t worry. You don’t need a detective badge. You just need a few simple checks and a bit of curiosity.
In this guide, we’ll walk through how to confirm WCCP is doing its job. We’ll keep it simple. We’ll keep it fun. And we’ll make sure you end up feeling like a FortiGate wizard.
TL;DR: To confirm WCCP is working on a FortiGate firewall, check the WCCP session status in the CLI, verify cache engine registration, monitor traffic counters, and confirm redirection is happening. Use diagnostic commands like diagnose sys wccp and review logs. If traffic flows through the cache engine and counters increase, you’re good. If not, it’s time to troubleshoot.
First, What Is WCCP (In Simple Terms)?
WCCP stands for Web Cache Communication Protocol.
It allows your FortiGate firewall to redirect certain traffic to a cache engine or proxy server. Think of it like this:
- The firewall sees web traffic.
- It taps the proxy on the shoulder.
- It says, “Hey, take a look at this.”
The proxy then inspects, filters, or caches the traffic. Everyone is happy. Especially your bandwidth.
But happiness means nothing if it’s not actually working.
Step 1: Check if WCCP Is Enabled
Let’s start basic. Is WCCP even turned on?
Log into your FortiGate via CLI and run:
show system settings | grep wccp
Or check the full configuration:
config system settings
show
end
You should see WCCP configuration settings. If not, that’s your first issue.
No config. No WCCP.
Simple.
Step 2: Check WCCP Service Status
This is where the fun starts.
Run the following command:
diagnose sys wccp
This is your magic window.
You want to see:
- Registered cache engines
- Service group information
- Assignment details
- Packet counters
If you see zero cache engines, that’s not good.
If you see a cache engine IP listed? That’s promising.
No proxy registration means no redirection.
Image not found in postmetaStep 3: Confirm the Cache Engine Is Registered
The proxy or cache engine must register with the firewall.
In the diagnostic output, verify:
- Router ID is correct
- Cache engine IP appears
- Service group ID matches configuration
- Status shows active or assigned
If the cache engine does not appear:
- Check Layer 3 connectivity
- Confirm WCCP is enabled on the proxy
- Verify service group numbers match
- Make sure firewalls between devices allow GRE traffic
Yes. GRE. That’s important.
WCCP uses GRE tunnels for traffic redirection.
If GRE is blocked, WCCP won’t work. Ever.
Step 4: Check Traffic Counters
This is the moment of truth.
In the WCCP diagnostic output, look at packet counters.
These counters should increase when users browse the web.
If numbers go up:
Congratulations. Traffic is being redirected.
If counters stay at zero:
Something is broken.
Try generating traffic manually. Open multiple websites from a client machine. Then check counters again.
No movement? Time to dig deeper.
Step 5: Verify Firewall Policy Matches
WCCP works only if traffic matches firewall policies.
Check:
- Source interface
- Destination interface
- Service (HTTP, HTTPS)
- NAT settings
If traffic bypasses the policy tied to WCCP, it won’t be redirected.
Policies are gatekeepers.
Wrong gate. Wrong result.
Step 6: Sniff the Traffic (Advanced but Fun)
Feeling adventurous?
Use packet sniffing.
diagnose sniffer packet any "host <proxy IP>" 4
This lets you see if traffic flows between FortiGate and proxy.
If you see GRE packets:
That’s good news.
No GRE traffic?
Investigate network paths and filters.
Step 7: Check Logs
Logs never lie. Well, almost never.
Go to:
- Log & Report
- Traffic logs
Look for:
- Sessions involving proxy IP
- Forwarded traffic entries
- Unexpected denies
If traffic appears between FortiGate and proxy, WCCP likely works.
If you see denied GRE packets, you found your culprit.
Step 8: Verify Proxy Is Receiving Traffic
Now switch to the proxy side.
Ask these questions:
- Is it receiving requests?
- Are logs filling up?
- Are sessions increasing?
If the FortiGate says it’s redirecting traffic, but the proxy sees nothing, something is off.
Networking is a two-way street.
Common Problems and Quick Fixes
| Problem | What You See | Likely Cause | Fix |
|---|---|---|---|
| No cache engine listed | Empty registration info | Proxy not registering | Check WCCP service ID and connectivity |
| Counters at zero | No packet increase | Policy mismatch | Adjust firewall policy |
| No GRE traffic | No tunnel packets | GRE blocked | Allow GRE protocol |
| Traffic bypasses proxy | Direct internet access | Wrong policy order | Move WCCP policy higher |
| Proxy gets partial traffic | Some sites missing | Service group mismatch | Match service IDs |
Step 9: Confirm Service Group Configuration
WCCP uses service groups. Each has an ID number.
This number must:
- Match on FortiGate
- Match on proxy
- Match across all routers involved
A mismatch equals silence.
Double-check with:
config system wccp
show
end
Look carefully. Typos happen more than we admit.
Step 10: Perform a Live Browsing Test
This one is simple.
Open a browser from a client behind the firewall.
Visit:
- News websites
- Video platforms
- Random blogs
Then check:
- WCCP counters
- Firewall sessions
- Proxy logs
If everything increases at the same time, you’ve confirmed success.
It’s like watching three meters go up together.
Beautiful.
Bonus Tip: Use Debug Mode (Carefully)
If things still don’t make sense, enable debugging.
diagnose debug enable
diagnose debug application wccp -1
This provides detailed output.
Warning: It can get noisy.
Disable it after testing:
diagnose debug disable
Use this only during maintenance windows if possible.
Signs That WCCP Is Definitely Working
Here’s your success checklist:
- Cache engine is registered
- Assignment status is active
- Packet counters increase
- GRE traffic visible
- Proxy logs show requests
- Users’ traffic passes through proxy
If you check most of these boxes, relax.
You did it.
Final Thoughts
Confirming WCCP is working on a FortiGate firewall isn’t hard.
It just requires a methodical approach.
Start simple.
Check registration.
Review counters.
Verify traffic flow.
Most problems come down to:
- Service ID mismatches
- GRE being blocked
- Firewall policy order
Remember. Firewalls follow rules strictly. They don’t guess. They don’t assume. They follow configuration exactly as written.
So when WCCP doesn’t work, it’s not magic. It’s configuration.
Take it step by step.
And soon you’ll not just confirm WCCP is working.
You’ll understand why it’s working.
And that’s even better.
