If you cannot fix a broken network, your entire organisation grinds to a halt: users cannot access email, customers cannot place orders, and security vulnerabilities go unnoticed. That is why every Fortinet professional must master a structured troubleshooting methodology and know exactly which tools to use for each type of problem. This chapter gives you a clear, repeatable process to diagnose and resolve network issues, even when you are starting from zero IT experience.
Jump to a section
A simple way to picture Troubleshooting Methodology and Tools
A master chef runs a busy restaurant kitchen.
When a customer complains that their steak is raw, the chef does not just shout at the grill cook. She follows a systematic method. First, she gathers information: she asks the customer exactly how raw it is, and she checks the ticket to see what temperature was ordered. Then she forms a hypothesis: perhaps the grill's temperature gauge is faulty, or the cook is rushing. She isolates the variable by checking the grill thermometer with a handheld probe. She tests her hypothesis by cooking a small piece of meat as a sample. If it cooks correctly, she now knows the problem is with the cook's timing. She documents the exact temperature, the cook's name, and the time. Finally, she implements a fix: she retrains the cook and adds a timer system.
This is exactly how an IT troubleshooter works. The customer complaint is a network fault. The ticket is a network log. The grill thermometer is a diagnostic command like 'ping'. The handheld probe is a packet capture tool. The sample piece of meat is a controlled test of a single component. The written record is a troubleshooting log. The retraining and timer system are configuration changes and alerts. Without this method, the chef would change random things and possibly ruin more steaks. In IT, that same scattershot approach would crash servers or block legitimate traffic.
Troubleshooting is a systematic process for finding and fixing problems. It is not about guessing or trying random commands. It is a logical, step-by-step method that engineers use every day to resolve network faults, misconfigured firewalls, and connectivity black holes. The goal is to identify the root cause as quickly as possible without causing additional damage.
The most widely used framework is the "OSI model" approach. The OSI (Open Systems Interconnection) model is a seven-layer framework that describes how data travels from one device to another. Think of it like a postal service: your letter (data) is sealed in an envelope (Layer 5), addressed (Layer 3), posted (Layer 2), and physically delivered by a truck (Layer 1). When something breaks, you start at the bottom (physical cables) and work your way up, or you start in the middle if you have a clue. For the NSE7 exam, you focus on Layers 2, 3, 4, and 7.
A systematic troubleshooting methodology consists of six core steps:
Define the problem. What exactly is wrong? "The internet is down" is useless. "Users in the sales office cannot reach the web server at 10.0.0.50" is specific.
Gather information. Collect logs, error messages, and configuration files. Use tools like ping, traceroute, and packet captures.
Form a hypothesis. Based on the evidence, propose a likely cause. For example: "The firewall rule blocking port 443 is misconfigured."
Test the hypothesis. Make a change in a controlled way. Change only one variable at a time. If you change three things at once, you will not know which fix worked.
Implement a solution. Once you confirm the root cause, apply the permanent fix.
Document and verify. Write down what you did and confirm the problem is resolved. This prevents repeating the same work later.
Now, let us dive into the specific tools a Fortinet professional uses. The most fundamental tool is the command-line interface (CLI) on a FortiGate firewall. The CLI is where you type text commands rather than clicking buttons. Key commands include:
'get system interface' – shows IP addresses and status of every port.
'get system performance' – shows CPU and memory usage. High CPU often means a denial-of-service attack or a misconfigured rule.
'diagnose debug flow' – traces a packet as it moves through the firewall, showing every rule decision. This is the single most powerful tool for packet-drop issues.
'execute ping' – sends a small packet to a destination to test basic connectivity.
'execute traceroute' – shows the path packets take through a network.
Ping works by sending an Internet Control Message Protocol (ICMP) echo request. If the destination replies, you have Layer 3 connectivity. Traceroute works by sending packets with increasing "time to live" (TTL) values, forcing each router to reveal its identity.
Packet capture tools like tcpdump (on Linux) or the FortiGate's built-in sniffer ('diagnose sniffer packet') capture all network traffic for analysis. You can see exactly what packets are being sent and received, including the source and destination IP addresses, ports, and protocol types. This helps you determine if traffic is being blocked, dropped, or misrouted.
Another critical concept is "log levels." FortiGate logs events at different severity levels: Emergency (system unusable), Alert (immediate action needed), Critical (major failure), Error (non-critical failure), Warning (potential issue), Notice (normal but significant), Information (general info), and Debug (detailed troubleshooting). For NSE7, you must know which logs to check for specific problems.
Why does all this matter? Before systematic troubleshooting, engineers would reboot devices randomly or change routing tables arbitrarily. This caused outages and made problems worse. The methodology replaces chaos with order. It saves time, reduces mistakes, and gives you a repeatable process that works regardless of the specific technology.
A common scenario: a user cannot access a web server. Instead of restarting the firewall, you would:
Ping the server's IP from the user's computer. If it fails, check the network cable (Layer 1).
Ping the firewall interface. If that works, the problem is beyond the firewall.
Use 'diagnose debug flow' to see if the firewall is blocking the traffic.
Check logs for a denied entry.
Locate the offending policy and modify it.
This logical progression isolates the problem without disrupting other services.
Finally, remember the 80/20 rule. 80% of problems are caused by human error: misconfigured rules, mistyped IP addresses, or forgotten passwords. Only 20% are actual hardware failures. So always check the configuration first.
Define the Problem
Ask the user: what exactly is not working? Which application? Which server? From which location? Get the exact error message. For example, 'The web sales portal at https://sales.example.com shows 'connection refused' from the finance team's computers.' This gives you a precise target to investigate.
Gather Information from Logs and Tools
Log into the FortiGate CLI and check the logs for the user's source IP and the destination server. Use 'get system interface' to verify link status. Use 'execute ping' to test Layer 3 connectivity. Use 'execute traceroute' to see the route. Collect all data before forming any theory.
Form a Hypothesis Based on Evidence
If ping works but the web page does not load, your hypothesis could be: 'A firewall policy is blocking TCP port 443, or the server's web service is down.' Write down your guess and why you think so based on the logs.
Test the Hypothesis with a Controlled Experiment
Enable 'diagnose debug flow' with a filter for the user's source IP and the server's IP. Send a test request from a computer. Observe the debug output. Does the firewall show 'allow' or 'deny'? If it shows 'deny', note the policy ID and the reason (e.g., 'policy-deny'). If it shows 'allow' but the connection still fails, the problem is on the server side — test with 'telnet <server-ip> 443'.
Implement the Solution and Verify
If you found a misconfigured policy, edit it using 'config firewall policy', change the action to 'accept', and commit. Then immediately repeat the test: ping, curl, or browse to the web page. Verify that the problem is resolved. If not, revert the change — you may have misidentified the cause.
Document Everything and Close the Loop
Write down the symptoms, the diagnostic commands used, the debug output, the exact change made, and the verification result. Update the helpdesk ticket with this information. This documentation helps if the issue reappears and helps your team learn from the experience.
Meet Sarah, a junior network engineer at a mid-size logistics company. It is 9 AM on Monday, and the helpdesk phone is ringing. The dispatch team cannot access the cloud-based tracking system. Every computer in the warehouse shows a "connection timed out" error.
Sarah does not panic. She opens her FortiGate firewall's web interface and checks the dashboard. The CPU usage is at 15% - normal. Memory is at 40% - normal. She moves to the CLI and types 'get system interface' to see all ports. The WAN interface shows status 'up' and an IP address from the internet provider, so the connection to the outside world is alive.
Next, she uses 'execute ping 8.8.8.8' (a Google DNS server). She gets replies, confirming internet connectivity. Now she knows the problem is not the ISP link. She pings the cloud tracking system's IP address, which is 203.0.113.50. That ping fails completely - no replies. This tells her the traffic is being blocked or misrouted somewhere.
Sarah then uses 'execute traceroute 203.0.113.50'. The trace shows the packets leave the FortiGate, reach the first router, then stop at the second hop. The second hop is the next-hop router in her own corporate network. So the problem is inside her own infrastructure, not at the cloud provider.
Now she needs to see why those packets are being dropped. She enables 'diagnose debug flow' and filters by the cloud server's IP address. She sends a test packet from her workstation. The debug output shows:
The packet arrives on the internal interface.
It matches a firewall policy that should allow HTTPS (port 443).
But then it hits a "deny" policy for the destination IP range.
Sarah has found the issue: a new firewall rule was added last Friday by another engineer to block a known malicious IP range. Unfortunately, that rule's IP range accidentally included the cloud tracking system's address.
She logs the session ID from the debug output. She uses 'show full-configuration | grep 203.0.113.50' to locate the exact policy. She finds policy ID 32. She enters configuration mode and types 'edit 32', then 'set action accept', then 'end'. She confirms the change with 'execute commit'.
She then verifies by pinging the cloud server again — it succeeds. She runs 'diagnose debug flow' once more to confirm the packet is being allowed. Finally, she writes a brief email to the team: "Resolved connectivity to cloud tracking system. A firewall policy was blocking traffic due to an overlapping IP range. Corrected policy ID 32. Change tested and verified."
She also opens a ticket in the helpdesk system with a full description of the symptoms, the diagnostic steps, and the solution. This documentation will help anyone else facing the same issue.
The entire process took 22 minutes. Without a methodical approach, Sarah might have spent hours rebooting switches, calling the ISP, or resetting the cloud account password. Instead, she identified the root cause quickly and fixed it without disrupting other traffic.
The NSE7 Advanced Security exam tests your ability to use Fortinet-specific troubleshooting tools and apply a structured methodology. Expect two types of questions: scenario-based multiple-choice and tool-identification questions.
Scenario questions present a network problem with symptoms. You must choose the correct first step, the correct tool to use, or the correct interpretation of a debug output. Common traps include:
Choosing a reboot as the first step. Rebooting is nearly always wrong unless a firmware update explicitly requires it. Always choose a diagnostic step first.
Choosing 'traceroute' when the problem is clearly a firewall rule. Traceroute shows routing, not firewall decisions. Use 'diagnose debug flow' for firewall issues.
Choosing 'ping' when you need to test a specific port (e.g., HTTPS on port 443). Ping tests ICMP, not TCP. The correct tool is 'telnet' or 'nc' (netcat) to test port reachability.
The exam loves to test the following concepts:
The correct sequence of troubleshooting steps. They may present a list and ask you to reorder them. The correct order is always: define, gather, hypothesise, test, implement, document.
The difference between 'diagnose debug flow' and 'diagnose sniffer packet'. Debug flow shows firewall policy decisions. Sniffer shows raw packet contents. Many candidates confuse them.
The meaning of common log messages. For example, a log entry with 'action=drop' and 'reason=policy-deny' means a firewall policy is blocking the traffic. A log with 'reason=timeout' means the server did not respond.
Which tool to use for each layer of the OSI model. Layer 1 (cables) – visual inspection or link lights. Layer 2 (switching) – 'get system arp' to see MAC addresses and IP associations. Layer 3 (routing) – 'execute traceroute' or 'get router info routing-table'. Layer 4 (ports) – 'telnet' or 'diagnose sys tcpsock'. Layer 7 (application) – packet capture or logs.
Configuration backup. A common question asks: "Before making a change, what should you do?" The answer is always: back up the current configuration. FortiGate uses 'execute backup config tftp <server-ip> <filename>'.
The 'diagnose debug' command hierarchy. For example, 'diagnose debug enable' turns on debugging, and 'diagnose debug disable' turns it off. 'diagnose debug flow' has sub-commands like 'set addr' to filter traffic. The exam expects you to know the exact syntax for common filter options.
The 'get' vs. 'show' commands. 'get system interface' shows runtime status. 'show system interface' shows the stored configuration. This distinction appears in exam questions frequently.
Trap pattern: the exam might describe a scenario where a user cannot access a web server, and all pings succeed. The trap answer is 'the server is offline'. The correct answer is 'the firewall is blocking the TCP port, or the server's firewall is blocking the port'. Ping succeeds because ICMP is often allowed even when TCP is blocked.
Trap pattern: timeouts. If a debug flow shows 'timeout' without a deny, the issue is on the server side, not the firewall. Many candidates incorrectly assume the firewall is dropping the traffic.
Trap pattern: overlapping policies. The exam loves to present a situation with multiple matching policies. The correct answer is that the first matching policy in the order wins, unless there is an explicit 'deny' earlier. You need to read the policy ID sequence.
Key definitions to memorise:
'ping': Layer 3 connectivity test using ICMP.
'traceroute': Layer 3 path discovery.
'telnet': Layer 4 port test (TCP only).
'diagnose debug flow': firewall policy decision tracer.
'diagnose sniffer packet': raw packet capture.
'get system performance': CPU/memory usage.
'execute backup config': saves configuration.
'show full-configuration': prints all settings.
'get system arp': shows IP-to-MAC address table.
Always define the problem with specific IP addresses, ports, and error messages before touching any configuration.
Use 'diagnose debug flow' to see exactly why a firewall is permitting or dropping a packet, not just that it is occurring.
Change only one variable at a time when testing a hypothesis; changing multiple things makes it impossible to know what fixed the issue.
Before making any configuration change, back up the current FortiGate configuration using 'execute backup config tftp'.
A successful ping does not guarantee a successful TCP connection; firewalls can block specific ports while allowing ICMP.
Traceroute can show silent hops where firewalls drop ICMP — a timeout does not mean the network cable is broken, only that a device chose not to reply.
Document every step and result, even if the fix seems obvious; future you or a colleague may need that record.
These come up on the exam all the time. Here's how to tell them apart.
ping
Tests one-way connectivity to a single destination IP using ICMP
Does not show the path packets take
Works at Layer 3 (Network layer)
traceroute
Shows every router hop along the path to the destination
Uses ICMP with increasing TTL values
Also works at Layer 3 but provides path information
diagnose debug flow
Shows firewall policy decisions: allow or deny per packet
Includes policy ID and reason for drop (e.g., policy-deny)
Does not show full packet payload, only metadata
diagnose sniffer packet
Captures and displays full packet contents (headers and payload)
Does not show which firewall policy matched
Useful for inspecting application data or DNS queries
get system interface
Shows live runtime status of interfaces (up/down, speed, errors)
Useful for real-time fault diagnosis
Output changes dynamically as links change
show system interface
Shows the configured settings from the stored configuration file
Does not reflect current link status
Useful for verifying intended configuration
execute ping
Tests ICMP connectivity at Layer 3
Does not test a specific application port
Successful ping does not guarantee TCP service is working
telnet <ip> <port>
Tests TCP connectivity to a specific port at Layer 4
Directly tests if a service (HTTP, HTTPS, SSH) is listening
A successful connection confirms the port is open and the service is responsive
Layer 3 problem
Affects all traffic to the destination IP, regardless of port
Symptoms: ping fails, traceroute fails
Causes: routing error, wrong subnet mask, down interface
Layer 4 problem
Affects only specific ports or services
Symptoms: ping works but web browser fails
Causes: firewall blocking port, server service not listening
Mistake
Ping failing always means the destination server is down.
Correct
Ping failing can also mean a firewall (either local or on the path) is blocking ICMP traffic, or the server is set to ignore ping requests. TCP connections like HTTPS may still work.
Many networks disable ICMP for security reasons, so beginners jump to wrong conclusions when ping fails.
Mistake
Traceroute shows all network devices, including firewalls, along the path.
Correct
Traceroute only shows routers that respond to ICMP. Many firewalls are configured to drop traceroute packets, so they will appear as a 'hop' that times out. This does not mean the firewall is broken.
Beginners expect every device to appear, and they think a missing hop means a failure.
Mistake
If the firewall log shows 'allow', the traffic definitely reached the destination server.
Correct
'Allow' only means the firewall permitted the traffic out. The server may still be down, or a second firewall on the server side may block it, or the server's application may be crashing.
The log only shows the decision of that specific firewall, not the entire end-to-end path.
Mistake
Rebooting a firewall is a safe first troubleshooting step.
Correct
Rebooting should be a last resort. It clears logs, terminates active sessions, and may cause data loss. Always try diagnostic tools first to identify the root cause without disrupting users.
In home IT, rebooting fixes many problems. In enterprise networks, it causes service interruptions and loses valuable diagnostic evidence.
Mistake
Packet captures show everything you need to know about a problem.
Correct
Packet captures show raw traffic but do not show firewall policy decisions. You need to combine packet captures with debug flow output to understand why a packet was dropped or allowed.
Beginners think capturing all traffic is the ultimate tool, but they often miss the 'why' behind the traffic flow.
Mistake
A high CPU usage on the firewall always means a hardware failure.
Correct
High CPU is often caused by too many firewall rules, a denial-of-service attack, or a misconfigured inspection profile (such as antivirus or intrusion prevention). Check the 'get system performance' output to identify the specific process causing the load.
Hardware failure is rare; software misconfiguration is common. Beginners default to the most dramatic explanation.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A ping failure means the ICMP echo request received no reply, often due to a firewall blocking ICMP or a routing issue. A connection timeout means a TCP connection attempt (like HTTPS on port 443) received no response within a time limit, often because the server is down or a firewall is dropping the TCP SYN packet.
Type 'diagnose debug enable', then 'diagnose debug flow filter addr <source-ip> <destination-ip>', then reproduce the traffic. The output shows each policy it matches and the final action (allow or deny). Type 'diagnose debug disable' to stop.
No. Rebooting clears all logs and diagnostic data. Always use troubleshooting tools first to identify the root cause. Only reboot as a last resort after backing up the configuration and exhausting other options.
Asterisks mean that router did not reply to the ICMP probe. Many firewalls and routers are configured to drop ICMP for security. It does not necessarily mean the device is faulty.
'get system performance' — to check CPU and memory usage. Then 'get system interface' to verify link status and IP addresses. These two commands give you a health snapshot of the device.
Use 'telnet <server-ip> 443' from the command line. If you get a blank screen or a banner, the port is open. If you get 'Connection refused' or 'Connection timed out', the port is closed or blocked.
Logs are a starting point, but they do not show real-time packet flow. You must combine logs with 'diagnose debug flow' to see the exact path and decision for a specific traffic stream.
You've finished Troubleshooting Methodology and Tools. Continue through the NSE7 study guide to build a complete picture of the exam.
Done with this chapter?