Technical Tip: How to troubleshoot if traffic is being intermittently dropped when passing through the FortiGate
| Description | This article describes what to follow if the traffic is stopped flowing intermittently over the Firewall. |
| Scope | FortiGate. |
| Solution | Verify what kind of traffic is dropping: check whether it is internal or external.
If the internal traffic is getting dropped, make sure that the FortiGate can reach the device; if FortiGate fails, it is required to investigate the very next hop.
If external traffic is getting dropped, follow the following steps to identify the cause.
Step 1: Verify whether FortiGate has internet or not, by pinging the gateway of the WAN interface and any external IPs
If Traffic fails to follow Step 2, move forward to Step 3.
Step 2: If no replies, it might be that the FortiGate does not have the ARP entry of the WAN, and if it does then the issue is with the ISP end or the wrong gateway set on the firewall: Troubleshooting Tip: Internet connectivity issue resolution on a FortiGate unit.
If the issue is intermittent and it is not possible to capture this information while it is happening, it is possible to capture more information by setting up either a link-monitor or a Performance SLA if in SD-WAN. If the ping to the ISP gateway is fine, but the ping to the internet fails, it is probably an ISP issue.
Step 3: If FortiGate has internet, verify the packet flow by following the logs and confirm whether the traffic is going out from the correct interface and the correct policy: Debugging the packet flow to confirm traffic flow.
A Windows PC running PowerShell can be used to perform a continuous ping with a timestamp. Including a timestamp in the ping output makes it easier to correlate packet loss with the debug flow.
ping.exe -t <IP address to ping>|Foreach{"{0} - {1}" -f (Get-Date),$_}
PS C:\Users\user> ping.exe -t 8.8.8.8|Foreach{"{0} - {1}" -f (Get-Date),$_}
Note: Make sure traffic originates from the source machine behind the firewall, and the destination should be defined in the debug.
Step 4: If traffic is allowed from the firewall on the correct interface and policy. Collect the session table for the source and destination.
Here are the commands to confirm:
diagnose sys session filter clear diagnose sys session filter src x.x.x.x diagnose sys session filter dst y.y.y.y diagnose sys session list
After this, confirm if there is any traffic shaping applied to the session, and follow step 5 to confirm if traffic is dropping due to Traffic shaping or not.
The following is an example: Troubleshooting Tip: Traffic shaping.
Step 5: If traffic shaping is configured, see Technical Tip: Important Changes to Traffic Shaping on FortiGate with NP7 Queuing-Based Traffic Management (QTM) Module.
Troubleshooting: Troubleshooting Tip: How to check packet drop by traffic shaper in NP6, NP6xlite and NP6lite unit.
Step 6: Remove the Traffic shaping. If traffic then starts working, it confirms that the behavior matched what was described in the article above. Apply the changes mentioned in the same article.
Step 7: If the DoS Policy is configured, verify if it is causing the issue. Troubleshooting: Technical Tip: Identifying packet drops caused by DOS Policy.
If all of the above steps fail to determine the issue, collect all necessary logs mentioned in the above articles and create a case with TAC for further troubleshooting. |