Exam objective 7.3 focuses on applying structured troubleshooting using packet captures, debug logs, and CLI commands. This concept matters because in the real world, networks fail in puzzling ways, and without a systematic method, you'll waste hours guessing. For PCNSE, mastering this structured approach is the difference between failing and passing when you face scenario-based questions that require logical diagnosis.
Jump to a section
A simple way to picture General Troubleshooting Methodology and Tools
First, you realise your car key is missing, which leads to a frantic search. This is exactly like a network problem occurring: something stops working, and you must find the root cause. You start by retracing your steps: did you have it when you came in from the garage? Did you put it in your pocket, on the kitchen counter, or in your bag? This is the equivalent of establishing a baseline: what changed just before the problem happened? You then use a flashlight to look under the sofa, in the car cup holder, and in the laundry basket. This corresponds to using tools: packet captures to look at the data traffic, debug logs to see what the firewall was thinking, and CLI commands to check system status. If you find the key under the sofa, you don't stop there — you ask, "Why did it fall there?" That's the troubleshooting methodology: fix the symptom, but also understand the underlying cause so it doesn't happen again. The entire process from realising the key is gone to confidently driving away mirrors the structured, step-by-step approach a security engineer uses to diagnose and resolve a network issue.
This analogy maps precisely to the structured troubleshooting methodology because both start with recognising a problem, move through systematic checking of possible causes using specific tools (physical search vs. CLI logs), and end with confirmation that the fix worked. It's not generic because the scenario has a clear start (missing key), defined tools (flashlight), and a logical sequence — exactly like network troubleshooting.
Troubleshooting in networking is a systematic process of identifying, diagnosing, and resolving problems that prevent a network from functioning correctly. Think of it as a detective investigating a crime: you gather clues, analyse evidence, and logically deduce what happened. In the context of a Palo Alto Networks firewall, problems can arise from misconfigured security policies, routing issues, application identification failures, or even hardware faults. The goal is to restore normal service as quickly as possible while preventing the same issue from recurring.
The general troubleshooting methodology follows a logical progression. First, you define the problem clearly. Instead of saying 'the internet is slow,' you would say 'users in the sales department cannot reach the CRM application hosted at 203.0.113.50 on port 443.' This precision narrows your investigation. Second, you gather information. This involves checking the firewall's system logs, interface status, and running configuration. You might use CLI commands like 'show system info' to verify the firewall is up, or 'show routing route' to confirm the route to the destination exists.
Third, you isolate the cause. This is where tools like packet captures and debug logs become invaluable. A packet capture records all the network traffic passing through a specific interface. It lets you see exactly what data is being sent and received. For example, if a user claims a connection fails, a packet capture can reveal whether their request ever reaches the firewall, or if the firewall is sending a reset (RST) packet. Debug logs, on the other hand, show the internal decision-making process of the firewall. For instance, the 'debug dataplane packet-diag' command can show why a specific packet was dropped — perhaps due to a security policy, or because it didn't match a route.
Fourth, you implement a fix based on your findings. If the debug log showed a security policy denying traffic because the application was misidentified as 'web-browsing' instead of 'salesforce,' you would create a more specific policy. After applying the change, you verify the problem is resolved by repeating the same test that initially failed. Finally, you document what happened and why. This isn't just busywork — it helps you and your team avoid the same mistake and provides a reference for future issues.
Why does this methodology exist? In the early days of networking, troubleshooting was often a chaotic process of randomly changing settings and hoping something worked. This approach was slow, unreliable, and could make the problem worse. The structured methodology replaces guesswork with logic. It ensures you don't overlook obvious steps, like checking if a cable is unplugged, before diving into complex analysis. For the PCNSE exam, you must understand this process because the questions will present you with symptoms and logs, expecting you to choose the correct next step — not just guess.
The tools themselves are specific to Palo Alto Networks. Packet captures can be taken inline from the firewall's web interface using 'Monitor > Packet Capture' or via CLI with 'tcpdump' on the dataplane. Debug logs require enabling specific debug commands on the CLI, such as 'debug dataplane drop' to see dropped packets. Common CLI commands you must know are: - 'show counter global filter delta yes' to see real-time packet counters. - 'test security-policy-match' to simulate traffic and see which policy it matches. - 'show log system' to view system events like interface status changes. - 'show session all' to view active sessions and their state.
Each command gives a different piece of the puzzle. Using them together in the correct order — problem, gather, isolate, fix, document — is the heart of structured troubleshooting. This replaces the old trial-and-error approach with a reliable, repeatable process that any IT professional can follow.
Define the Problem
You must describe the issue in specific terms: which users, which application, which IP address, and what symptoms. This narrows the search and prevents wasted effort. For example, 'The sales team on VLAN 10 cannot reach the CRM at 203.0.113.50 on port 443' is much better than 'Internet is slow.'
Gather Information
Use tools like CLI commands ('show system info', 'show interface', 'show routing route'), system logs, and baseline data to collect facts. This step builds the foundation for isolation. You might check if the interface is up, if the route exists, and if any recent changes were made.
Isolate the Cause
Run targeted tests such as 'test security-policy-match' for policy issues, packet captures for traffic analysis, or debug logs for internal firewall decisions. Compare the findings with expected behaviour. This step identifies the exact component that is failing, whether it's a policy, a route, or an interface.
Implement a Fix
Based on the isolated cause, apply the correct change. For instance, modify an incorrect security policy, add a missing route, or correct a zone assignment. Always take a configuration backup before making changes. After the change, commit the configuration.
Verify and Document
Reproduce the exact test that initially failed to confirm the problem is resolved. For example, if the user couldn't reach the CRM, have them try again or run 'test security-policy-match' again. Then document the issue, root cause, fix, and any lessons learned. This step ensures the problem is truly fixed and helps prevent future recurrence.
Consider a real scenario: A mid-sized company has 500 employees using a Palo Alto Networks PA-5250 firewall as their primary internet gateway. One Tuesday morning, the finance team reports they cannot access their cloud-based accounting software at https://finance.example.com. The helpdesk escalates the ticket to you as the network security engineer.
You start by defining the problem precisely. You ask: 'Which specific users are affected? Is it everyone in finance, or only certain ones? Does it affect other websites?' The finance team reports that all five members on the third floor can't reach the accounting site, but they can access Google and the internal HR portal. This tells you it's not a complete internet outage — it's a targeted block or routing issue.
Next, you gather information. You SSH into the firewall and run these commands: - 'show system info' to confirm the firewall is running normally. - 'show interface ethernet1/1' to check the internet-facing interface is up. - 'show routing route 203.0.113.50' to verify the route to the accounting software's IP address exists. - 'test security-policy-match source 10.10.10.50 destination 203.0.113.50 destination-port 443 application any' with a user's IP address to see which security policy the traffic matches.
The 'test security-policy-match' output shows the traffic is matching a policy named 'Deny-Block-Finance' with a source zone of 'Trust' and a destination zone of 'Untrust.' You don't remember creating that policy, so you suspect a recent change. You check the system logs with 'show log system | match Deny-Block-Finance' and see it was created two days ago by an intern who was 'cleaning up rules.'
Now you isolate the cause. The debug logs are not needed yet because the policy match command already identified the culprit policy. However, you want to be sure this policy is actually blocking the traffic. You enable packet capture on the Trust zone for a short time, filtering on the finance user's IP and destination port 443. You see the user's SYN packet reaching the firewall, but the firewall sends back a RST packet. This confirms the policy is actively denying the connection.
To implement a fix, you first take a backup of the configuration (a sensible precaution). Then you modify the 'Deny-Block-Finance' policy to allow the specific application 'ssl' (since it's HTTPS traffic) and remove the block action. You commit the change. To verify, you ask a finance user to try accessing the site again — it works. You then re-run 'test security-policy-match' to confirm the traffic now matches an allow rule.
Finally, you document the issue: 'Finance unable to access cloud accounting software due to newly created deny policy. Resolution: allowed SSL traffic to destination IP 203.0.113.50 on port 443. Root cause: unauthorised policy change.' You also send a note to your manager about the intern's mistake and suggest implementing a change management process.
The tools you used were:
CLI commands for verification and testing.
Packet capture to confirm packet behaviour.
System logs to find when the policy was created.
This structured approach prevented you from wasting time rebooting the firewall or reconfiguring routes. It directly targeted the cause.
The PCNSE exam tests objective 7.3 heavily through scenario-based questions. You will be given a description of a network problem — like 'Users in the sales VLAN cannot reach the internet' — along with partial output from CLI commands, packet captures, or debug logs. You must choose the correct next step, identify the root cause, or select the right tool to use.
Key exam topics include:
The correct order of steps in the troubleshooting methodology: define the problem, gather information, isolate the cause, implement a fix, verify, and document. Exam questions will often give you a sequence and ask which step is missing or out of place.
Using 'test security-policy-match' to determine which security policy applies to a specific traffic flow. This is a common tool you must know how to interpret.
Reading packet capture output to identify a TCP three-way handshake, a SYN flood, or a firewall sending an RST packet. You should be able to distinguish between a successful connection (SYN, SYN-ACK, ACK) and a blocked one (SYN then RST).
Understanding when to use debug logs versus packet captures. Debug logs are for internal firewall decisions, while packet captures show the actual traffic on the wire. The exam loves to trap you into using one when the other is more appropriate.
Common CLI commands like 'show counter global filter delta yes' to see real-time drops, and 'show session all' to see active sessions. You must know what each command does and when to run it.
Common traps the exam sets:
They might describe a problem where the traffic reaches the firewall but is then silently dropped. Beginners often think it's a routing issue, but the answer is that the session was denied by a security policy. You must check the session table or counters first.
They might show you a packet capture with a malformed packet (e.g., TCP checksum error) and ask what to do. The correct answer is to check the network interface for errors, not the firewall configuration.
They might ask you to troubleshoot a VPN tunnel that forms but tunnels no traffic. The trap is to look at routing first, but the real issue is often that the tunnel interface is not included in the correct security zones.
They might present a scenario where a user's traffic is being NAT'd incorrectly. The correct approach is to use 'show session id' and look at the post-NAT IP address.
Correct answer patterns:
If a question asks 'What should you do first?' the answer is almost always 'Define the problem precisely' or 'Gather more information using system logs,' not 'Change the policy immediately.'
If the question offers multiple CLI commands, pick the one that directly shows the relevant data: 'test security-policy-match' for policy matching, 'show session all' for active sessions, 'show routing route' for routes.
When a question mentions debug logs, they are almost always used to isolate a specific cause after other tools have narrowed it down.
Definitions you must memorise for this chapter:
Packet capture: A recording of raw network traffic on an interface.
Debug log: A detailed log that shows the internal processing logic of the firewall.
CLI command: A text-based command run on the firewall's command line interface.
Baseline: The normal state of the network before a problem occurs.
TCP handshake: The three-way process (SYN, SYN-ACK, ACK) that establishes a TCP connection.
Exam questions are typically multiple-choice with four options. Only one option will follow the structured methodology correctly. If two options seem plausible, eliminate the one that jumps to a conclusion without first verifying the cause.
Structured troubleshooting follows a logical order: define the problem, gather information, isolate the cause, implement a fix, verify, and document.
Packet captures show the actual network traffic, while debug logs reveal the firewall's internal decision-making process.
The 'test security-policy-match' CLI command simulates traffic to show which security policy it matches, but it does not guarantee the actual behaviour.
Debug logs should only be enabled temporarily during active troubleshooting to avoid performance degradation.
Always verify a fix by repeating the same test that initially failed before declaring the problem resolved.
A missing SYN-ACK in a packet capture does not necessarily mean the firewall is blocking the traffic; the server or routing could be the issue.
System logs provide a history of changes and events that can help you identify when a problem started or what was recently modified.
These come up on the exam all the time. Here's how to tell them apart.
Packet Capture
Shows raw network traffic on the wire
Used to see actual packets like SYN, ACK, RST
Captures data on a specific interface in real time
Debug Logs
Shows internal firewall decision-making
Used to see why a packet was dropped or permitted
Logs events triggered by specific debug commands on the firewall
test security-policy-match
Simulates traffic to show which policy matches
Does not affect live traffic
Requires manual input of source, destination, port
show session all
Shows actual live sessions currently on the firewall
Displays real traffic being processed
Can show session state, age, and NAT translations
System Logs (show log system)
Logs system events like interface up/down, commits, admin logins
Helps identify when changes were made
Does not show per-session details
Traffic Logs (show log traffic)
Logs individual traffic sessions
Shows source, destination, action (allow/deny), bytes transferred
Useful for auditing who accessed what
Mistake
Packet captures and debug logs show the same information, so it doesn't matter which one you use.
Correct
Packet captures show the actual traffic on the wire, while debug logs show the internal decision-making process of the firewall (e.g., why a packet was dropped). They are complementary tools, not interchangeable.
Beginners often confuse the two because both appear as text output. But packet captures focus on what data is flowing, while debug logs explain why the firewall acted the way it did. This misconception leads to using the wrong tool and missing the root cause.
Mistake
If a user cannot reach a website, the first step is to change the security policy to allow all traffic.
Correct
The first step is to define the problem precisely and gather information using tools like CLI commands, packet captures, or logs. Changing policies without analysis can introduce security holes and may not fix the issue.
This mistake is common because beginners panic and want to solve the problem immediately. They skip the diagnostic phase and jump to a fix, which is inefficient and risky. The exam tests your ability to resist this impulse.
Mistake
The 'test security-policy-match' command tells you whether traffic will be allowed or denied, so if it says 'deny,' the problem is always the security policy.
Correct
The command only simulates traffic and shows which policy matches, but the actual problem could be elsewhere, such as a routing issue or a firewall zone misconfiguration. You must verify with other tools like packet captures or session logs.
Beginners over-rely on simulation tools. They forget that a simulation doesn't account for dynamic factors like session table limits, NAT translations, or hardware acceleration. The exam traps you by presenting a simulation output that matches, but the real issue is something else.
Mistake
Debug logs can be left enabled permanently to help with future troubleshooting.
Correct
Debug logs consume significant firewall resources and should only be enabled for the duration of the specific troubleshooting session. Leaving them on can degrade performance and fill logs with unnecessary data.
Beginners think more information is always better. They don't realise that debug logging is a heavy operation that can cause packet drops or CPU spikes. The exam teaches you to use it sparingly and disable it after use.
Mistake
If a packet capture shows a SYN packet being sent but no SYN-ACK response, the firewall is blocking the traffic.
Correct
A missing SYN-ACK could indicate the server is down, a routing issue on the return path, or an intermediate firewall blocking the return traffic. The firewall sending an RST is a clear sign of blocking, but a missing response requires checking the server and routing.
Beginners assume every network problem is caused by the firewall. They forget that the firewall is only one part of the path. The exam tests your ability to consider the full network topology and not blame the firewall prematurely.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
A packet capture records the raw network traffic passing through an interface, showing you the packets themselves. A debug log shows the internal processing of the firewall, such as why it dropped a packet or which policy it applied. They are complementary: captures show 'what,' debug logs show 'why.'
You can take a packet capture from the web interface under Monitor > Packet Capture, or via CLI using the 'tcpdump' command on the dataplane. Set a filter for the traffic you want (e.g., host 10.1.1.50 and port 443) and start the capture. Save the output as a .pcap file for analysis in tools like Wireshark.
Use the 'test security-policy-match' command followed by the source and destination IP addresses, destination port, and application. For example: 'test security-policy-match source 10.1.1.50 destination 203.0.113.50 destination-port 443 application ssl'. The output shows the matching policy and whether it allows or denies the traffic.
First, check if the user is in a different IP range or zone that might have a different security policy. Use 'test security-policy-match' with the user's IP to see which policy applies. Also check for user-specific rules, authentication requirements, or client-side browser issues. System logs can show if the user's traffic is being blocked or dropped.
Debug logging consumes significant CPU and memory resources on the firewall. Leaving it enabled can degrade performance, cause packet drops, and fill the log storage with unnecessary data. Only enable debug logs for the specific session you are troubleshooting, and disable them immediately after you finish.
Repeat the exact test that initially failed. If the user could not reach a specific IP, ask them to try again or reproduce the test from your own machine if possible. Additionally, run the same CLI commands or packet captures you used during diagnosis to verify the traffic now flows as expected.
You've finished General Troubleshooting Methodology and Tools. Continue through the PCNSE study guide to build a complete picture of the exam.
Done with this chapter?