| Description |
This article describes how to identify the possible why WAD debugs might not show any output in the FortiGate CLI and how to fix this.
When troubleshooting WAD-related issues on FortiGate, there are a few scenarios where the debugs might not show up in the CLI even after enabling all the necessary debug commands. |
| Scope | FortiGate. |
| Solution |
WAD, which stands for WAN Optimization Daemon in FortiGate, handles several tasks apart from WAN optimization, namely proxying traffic, web filtering, web caching, etc. While troubleshooting WAD-related issues/crashes, debugs can be enabled using the following CLI commands.
FortiGate# diagnose wad debug enable ? FortiGate# diagnose debug enable Current debug duration is 30 minutes, 0 minutes 33 seconds have passed. <-- Look for this message.
But sometimes it may be noticed that even when debugs are enabled, no output might be printed in the CLI terminal. Here are a few possible reasons why this could be happening and how to address them.
Since the inspection mode can be manually changed either at the global settings or at the individual policy level on the FortiGate, verify first which mode is enabled for the traffic that is being troubleshooted. Note that the default inspection mode on the firewall policies is 'Flow-based' mode, and with this mode enabled, the GUI might not show the inspection mode section for some of the FortiGate models, as shown in the examples below. It will show the mode only if 'Proxy-based' mode is enabled manually, which might cause some confusion to identify which mode is currently enabled just by looking at this screen on the GUI.
Compare this with the below example, where inspection mode is manually changed to proxy mode using CLI (either global settings or per firewall policy), where the Inspection-mode now shows the new section clarifying which mode is active.
The WAD debugs will show outputs only for 'Proxy-based' mode, so verify which mode is active using the above steps. This can be reviewed from the CLI as well. In the below example, the inspection-mode is the default 'Flow-based mode', and with this mode again even in CLI, it might not show which mode is active with just the 'show' output. This behavior is expected.
FortiGate# config firewall policy FortiGate(policy) # edit "1" FortiGate(1) # show
Use the below 'show full' command to find the inspection-mode that is currently enabled.
FortiGate(1) # show full | grep inspection-mode
If WAD debugs are enabled with the above default flow-based configs, it will not print any debugs, which is expected. Review the requirement and (only) if proxy-based mode is needed, enable this config change and then re-enable the WAD debugs, which would then print the relevant debugs.
FortiGate# config firewall policy FortiGate(policy) # edit "1" FortiGate(1) # set inspection-mode proxy next
The 'diagnose debug info' CLI is commonly used to verify which process debugs are enabled. Below is an example output where wad debugs have been enabled at level -1, along with a wad filter. Note that while this seems like a central debug info command, it shows all the debugs enabled but does not include the debug filters. FortiGate# diagnose debug info ===== IPS debug settings ===== ===== IPS SSL debug settings ===== ===== IP router debug settings =====
PIM-DM Debugging status: Debugging status (0) : RIP debugging status:
RIPng debugging status:
Current debug duration is 30 minutes, 21 minutes 17 seconds have passed. <--- Shows debugs are enabled and active. FortiGate#
Note: Even if a diagnose debug reset is done, it does not reset the WAD filters.
FortiGate#
Now, check for the WAD filters using the below CLI command. As shown, the filters were not reset with the diag debug reset command, and the old filters are still active.
FortiGate# diagnose wad filter list FortiGate#
Here is the CLI to clear this specific WAD filter, which might have been causing the WAD debugs to not print due to an old filter previously applied.
FortiGate# diagnose wad filter clear FortiGate# diagnose wad filter list FortiGate#
Now, re-enable the WAD debugs (with or without filters as needed, but the general recommendation is to always enable debugs with a specific filter so that the outputs are not overwhelming), and the debug outputs printed on the terminal should appear.
Related articles: Technical Tip: Overview of WAD process structure Technical Tip: Using the 'diagnose wad debug' command to troubleshoot Explicit Web Proxy related iss...Troubleshooting Tip: Example of WAD debugging for Explicit Proxy |
