TTechclick ⚡ XP 0% All lessons
SonicWall · Next-Gen Firewall · TroubleshootingInteractive · L1 / L2 / L3

Troubleshooting SonicWall — Find the Drop, Read the Reason, Fix It

When traffic won't pass a SonicWall, guessing is the slow way. SonicOS lets you see exactly where a packet is dropped — an access rule, a NAT policy, a route or a security service — and why. This lesson walks the methodology, the Packet Monitor, the logs and Connections table that confirm a fix, and the Tech Support Report you collect before you ever call Support.

📅 2026-06-19 · ⏱ 16 min · 5 infographics · live packet demo · 🏷 10-Q assessment + AI Tutor inline

⚡ Quick Answer

A clear, interactive guide to troubleshooting a SonicWall firewall (2026): the 'where is it dropped?' methodology (access rule vs NAT policy vs route vs DPI/GAV/IPS/CFS), Packet Monitor with filters, mirror, per-packet verdict and pcap export, the Log/Event Monitor and Connections table to confirm, plus System Diagnostics and the Tech Support Report you collect before contacting Support.

🎯 By the end you will be able to

Read as:

Pick where you want to start

1

Where is it dropped?

Rule vs NAT vs route vs security service.

 2

Packet Monitor

Filters, mirror, drop reason, pcap export.

 3

Logs & Connections

Read drop messages, confirm the session.

 4

Diagnostics & TSR

Ping/DNS/traceroute, the TSR, worked flow.

🧠 Warm-up — 3 questions, no score

Just notice which ones make you pause. We answer all three inside the lesson.

1. When traffic won't pass, what's the first question?

Answered in Where is it dropped?.

2. Which tool shows the firewall's own verdict on each packet?

Answered in Packet Monitor.

3. What confirms a live session is actually being created?

Answered in Logs & Connections.

Most engineers think…

Most people troubleshoot a firewall by changing things until traffic flows — toggle a rule, rebuild a NAT, reboot, blame the ISP. That trial-and-error habit wastes hours and hides the real cause.

A SonicWall tells you exactly where a packet died if you ask it. The discipline is to localise the drop first — is it an access rule, a NAT policy, a route, or a security service (DPI/GAV/IPS/CFS)? — then use Packet Monitor to read the per-packet verdict and drop reason, and the Connections table and logs to confirm the fix. That single shift, from guessing to reading the firewall's own evidence, is what separates a slow ticket from a fast one.

① Where is it dropped? The methodology

When traffic doesn't pass a SonicWall, there is really only one useful question: where is the packet being dropped? Resist the urge to change things at random. Instead, reproduce the problem and localise the drop to one of four usual suspects.

The four suspects

An access rule can deny the zone-to-zone flow. A NAT policy can translate the address wrongly — or be missing for an inbound publish. A route can point traffic at the wrong next-hop or interface. And a security service — DPI, Gateway Anti-Virus, IPS or Content Filtering (CFS) — can silently block a flow that looks fine on paper.

The reason this matters: each suspect lives in a different place in SonicOS, and the firewall will tell you which one acted if you read its own verdict. Guessing the ISP is the cause is the classic time-sink when a DPI or CFS block is really to blame.

Figure 1 — The SonicWall troubleshooting loop
Don't guess — reproduce, localise the drop, read the reason, fix it, then confirm.The SonicWall troubleshooting loopReproducetrigger the failureLocaliserule/NAT/route/svcReaddrop reasonFixthe one componentConfirmConnections + logs
Don't guess — reproduce, localise the drop, read the reason, fix it, then confirm.
Figure 2 — The four suspects, in order
When a packet doesn't pass, it is almost always one of these four components dropping it.The four suspects, in orderAccess rulezone-to-zone allow / deny decisionNAT policyaddress translation, inbound publishRoutewrong next-hop or interfaceSecurity serviceDPI / GAV / IPS / CFS silently blocks
When a packet doesn't pass, it is almost always one of these four components dropping it.
Quick check · Q1 of 10 · Understand

Traffic won't pass a SonicWall. What is the right first move?

Correct: b. The whole methodology is to find the responsible component first. It is almost always an access rule, a NAT policy, a route, or a security service (DPI/GAV/IPS/CFS) — reading the firewall's verdict beats guessing or blaming the ISP.
👉 So far: Troubleshooting a SonicWall = one question: where is it dropped? Localise to an access rule, a NAT policy, a route, or a security service (DPI/GAV/IPS/CFS) before changing anything.

② Packet Monitor — the primary tool

The single most useful tool is Packet Monitor, under Investigate ▸ Tools ▸ Packet Monitor in SonicOS 7. It captures packets into the firewall's buffer and can also mirror matching packets out to an external analyser. What makes it special is that it shows the firewall's own handling of each packet — whether it was Forwarded, Consumed, Generated or DROPPED — and very often the drop reason or the module that acted.

Filter first, always

Set a tight filter before you reproduce: interface, source and destination IP, port and protocol. A capture with no filter grabs everything, so the one packet you care about is buried in noise — or the buffer fills before it even arrives. Once you have the capture you can export it as a pcap and open it in Wireshark for deeper analysis.

🔬
Packet Monitor
tap to flip

Investigate ▸ Tools. Filtered capture/mirror that shows the firewall's per-packet verdict (forwarded/consumed/generated/dropped) and the drop reason; exports a pcap.

📜
Event / Log Monitor
tap to flip

Investigate ▸ Logs. Categorised events with plain drop messages like 'dropped by access rule'; set filters and levels while testing.

🔗
Connections table
tap to flip

The Active Connections Monitor — live sessions with source, destination, zone, service and NAT. Confirms whether a flow is actually being created.

🧾
Tech Support Report
tap to flip

System ▸ Diagnostics. A full config/state export to attach when you open a case. Collect it before you contact SonicWall Support.

Filter before you capture

Always set a tight Packet Monitor filter — interface, source/destination IP, port and protocol — before you reproduce. An unfiltered capture buries the one packet you need in noise and can fill the buffer before the real packet even arrives.

Quick check · Q2 of 10 · Remember

What does Packet Monitor uniquely show that a capture on a PC does not?

Correct: a. Packet Monitor exposes the firewall's per-packet verdict and often the module/drop reason, so you see the SonicWall's decision, not just the bytes on the wire. You can also export a pcap for Wireshark.
👉 So far: Packet Monitor (Investigate ▸ Tools) captures/mirrors with filters and shows the firewall's verdict — forwarded/consumed/generated/dropped — plus the drop reason; export a pcap for Wireshark. Always filter first.

③ Logs / Event Monitor + the Connections table

Two more views confirm what Packet Monitor showed. The Log / Event Monitor (under Investigate ▸ Logs) lists events with categories, priorities and plain messages — including explicit drop lines like 'dropped by access rule' or 'no matching policy.' Set log filters and levels to focus on the affected flow and raise verbosity while you test.

The Connections table (the Active Connections Monitor) answers a different question: is a session even being created? It lists live flows with source, destination, zone, service and NAT mapping. If your flow never appears, the firewall isn't forwarding it; if it appears after a change, the path is at least being built. Packet Monitor tells you why a packet died; Connections tells you whether a session lives.

Figure 3 — The SonicOS troubleshooting toolkit
Each tool answers a different question — the firewall's verdict, its messages, the live session, and the plumbing.The SonicOS troubleshooting toolkitSonicOS 7Investigate + DiagPacket MonitorEvent / Log MonitorConnections tablePing / DNS / traceTech Support ReportSafeMode recovery
Each tool answers a different question — the firewall's verdict, its messages, the live session, and the plumbing.
Figure 4 — Packet Monitor vs the Connections table
They answer different questions — use both: one for the per-packet verdict, one for the live session.Packet Monitor vs the Connections tablePacket MonitorPer-packet verdict + drop reasonForwarded / consumed / droppedNeeds a tight filterExports a pcap for WiresharkConnections tableLive sessions, not packetsSource / dest / zone / NATIs a flow even created?Confirms the fix worked
They answer different questions — use both: one for the per-packet verdict, one for the live session.
Inbound publish = NAT policy AND access rule

Exposing an internal server to the WAN needs both a NAT policy (to translate the public address) and a matching access rule (to allow WAN ▸ the server's zone). Adding only the NAT is the single most common reason a 'published' server is still unreachable.

▶ Watch a published server go from DROPPED to reachable

How one inbound connection is handled end-to-end. Press Play for the diagnosis-and-fix path, then Break it to see the classic mistake.

① ReproduceUsers can't reach the published DMZ web server, so the admin opens a browser to the public IP on port 443 to trigger the inbound connection.
▼
② CaptureIn Packet Monitor the admin sets a tight filter on the server IP and TCP 443, then reproduces — the inbound SYN appears in the buffer.
▼
③ Read dropThe capture shows the SYN was DROPPED with reason 'no matching access rule'; the Connections table confirms no session was created.
▼
④ Fix + confirmThe admin adds the WAN ▸ DMZ access rule, re-tests, and Packet Monitor now shows the SYN Forwarded while Connections shows the live session.
Press Play to step through the diagnose-and-fix path. Then press Break it.
Quick check · Q3 of 10 · Apply

You added a rule and want to confirm a session is now actually being built. Where do you look?

Correct: a. The Connections table lists live sessions with source, destination, zone, service and NAT. If the flow now appears, the path is being built; Packet Monitor told you why a packet dropped, Connections confirms the session lives.
👉 So far: The Log/Event Monitor shows plain drop messages ('dropped by access rule'); the Connections table shows whether a live session is being created. One tells you why a packet died, the other whether the flow lives.

④ System Diagnostics, the Tech Support Report & a worked flow

System ▸ Diagnostics carries the everyday probes — ping, DNS name lookup, reverse-DNS lookup, traceroute and a core/system monitor — for checking reachability and name resolution. It is also where you generate the Tech Support Report (TSR): a full config and state export you download and attach when you open a case with SonicWall Support. Collect it before you call, not after. SafeMode is the separate recovery boot mode for a box that won't start normally.

The worked flow

Put it together: reproduce ▸ Packet Monitor with a tight filter ▸ read the drop and its reason ▸ inspect the responsible access rule / NAT policy / route / DPI setting ▸ fix ▸ re-test and confirm in Connections and the logs. The pitfalls that bite people: capturing with no filter, forgetting that an inbound publish needs both a NAT policy and an access rule, blaming the ISP when a DPI/CFS block is the cause, and contacting Support without a TSR ready.

Figure 5 — From symptom to closed ticket
The end-to-end flow: capture the drop, fix the one component, then prove it with Connections, logs and a TSR if you escalate.From symptom to closed ticketSymptomtraffic won't passCapturefiltered PacketMonitorDrop reasonrule / NAT / DPIFixthe named componentProve / TSRconfirm or escalate
The end-to-end flow: capture the drop, fix the one component, then prove it with Connections, logs and a TSR if you escalate.

Priya at Meridian Logistics in Kochi faces this

A newly published web server in the DMZ is unreachable from the internet, even though the team insists 'the NAT is added.'

Likely cause

The inbound publish has a NAT policy but no matching WAN ▸ DMZ access rule, so the firewall translates the address and then drops the packet.

Diagnosis

In Investigate ▸ Tools ▸ Packet Monitor, filter on the server IP and TCP 443 and reproduce. The inbound SYN arrives and is DROPPED with reason 'no matching access rule'; the Connections table shows no session is created.

Investigate ▸ Tools ▸ Packet Monitor + Policy ▸ Rules & Policies
Fix

Add the WAN ▸ DMZ access rule allowing the published service to the server, keeping the existing inbound NAT policy.

Verify

Re-run Packet Monitor — the SYN is now Forwarded — and the Connections table shows the live session; the log stops emitting the 'dropped by access rule' message.

Prove it, don't assume it

Never close a SonicWall ticket on a hunch. After a fix, re-run Packet Monitor to see the packet Forwarded, check the Connections table for the live session, and watch the drop message disappear from the logs. Three reads, zero guessing.

Quick check · Q4 of 10 · Analyze

Before escalating an unresolved issue to SonicWall Support, what should you have ready?

Correct: c. The TSR captures the full configuration and state in one file so Support has everything up front. Collecting it before you call is the difference between a fast case and a slow back-and-forth.
👉 So far: System ▸ Diagnostics gives ping/DNS/traceroute and the Tech Support Report (TSR) — a full config/state export to collect before contacting Support. Reproduce ▸ capture ▸ read ▸ fix ▸ confirm.

🤖 Ask the AI Tutor

Tap any question — instant, scoped to this lesson. No login, no waiting.

Pre-curated from vendor docs + community Q&A, scoped to this lesson. For a live prod issue, paste your export into chat.techclick.in.

📝 Wrap-up assessment — six more

You've answered 4 inline. Six left. 70% (7 of 10) marks the lesson complete on your profile. Tap Submit all answers at the end.

Q5 · Remember

In SonicOS 7, where do you find Packet Monitor?

Correct: b. Packet Monitor lives under Investigate ▸ Tools in SonicOS 7, alongside the diagnostic and logging tools used for troubleshooting.
Q6 · Remember

Which view confirms whether a live session is actually being created?

Correct: a. The Connections table lists active sessions with source, destination, zone, service and NAT mapping. If a flow never appears there, the firewall isn't forwarding it.
Q7 · Understand

A log line reads 'dropped by access rule.' Which component should you inspect?

Correct: c. The message names the cause directly: the access rule. Inspect and adjust the access rule that is denying the flow; the log message points straight at it.
Q8 · Apply

You publish an internal server to the WAN and add the NAT policy, but it's still unreachable. What is the most likely missing piece?

Correct: d. An inbound publish needs both a NAT policy and a matching access rule. The NAT translates the address, but without the access rule the firewall still drops the packet — Packet Monitor shows 'no matching access rule'.
Q9 · Analyze

Why is capturing with no filter in Packet Monitor a mistake?

Correct: d. An unfiltered capture grabs all traffic, so the single packet you care about is lost in the noise and the buffer may fill before it is captured. A tight filter on the affected IP and port isolates the drop.
Q10 · Evaluate

An interviewer asks for your end-to-end SonicWall troubleshooting method. Best answer?

Correct: b. The disciplined flow is reproduce ▸ filtered capture ▸ read the drop reason ▸ fix the responsible access rule/NAT/route/DPI setting ▸ confirm in the Connections table and logs. Guessing or rebooting wastes time and hides the cause.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the path that tripped you up and tap "Try again".

🧠 In your own words

Type one line: why is 'where is it dropped?' the right first question on a SonicWall, not 'is the ISP down?' Then compare with the expert version.

Expert version: Because the SonicWall itself records exactly what happened to each packet, while the ISP is just a guess. A failed flow is almost always dropped by one of four components on the firewall — an access rule, a NAT policy, a route, or a security service like DPI/GAV/IPS/CFS — and Packet Monitor will show the per-packet verdict and the drop reason that names the culprit. Localising the drop first, then confirming the fix in the Connections table and the logs, turns a vague 'internet problem' into a precise one-line cause and a tested fix — and gives you a clean Tech Support Report if you ever need to escalate.

🗣 Teach a friend

Best way to lock it in — explain it in one line to a teammate. Tap to generate a paste-ready summary.

📖 Glossary

Packet Monitor
SonicOS capture/mirror tool (Investigate ▸ Tools) that shows the firewall's per-packet verdict — forwarded, consumed, generated or dropped — and often the drop reason; exports a pcap.
Capture vs Mirror
Capture stores matching packets in the firewall buffer for inspection and export; mirror copies them out of an interface to an external analyser.
Drop reason / module
The firewall's stated cause for discarding a packet, such as 'no matching access rule' or 'no matching policy', shown per packet in the capture.
Access rule
A zone-to-zone allow or deny policy that decides whether traffic between two zones is permitted.
NAT policy
The rule that translates source or destination addresses, including the inbound publishing of internal servers to the WAN.
Connections (Active Connections Monitor)
The table of live sessions showing source, destination, zone, service and NAT mapping — confirms whether a flow is being created.
Log / Event Monitor
Investigate ▸ Logs view of categorised events with drop messages and adjustable filters and levels.
Tech Support Report (TSR)
A full configuration and state export from System ▸ Diagnostics, collected before raising a case with SonicWall Support.
DPI / GAV / IPS / CFS
Security services — Deep Packet Inspection, Gateway Anti-Virus, Intrusion Prevention and Content Filtering — that can silently block traffic.
SafeMode
A recovery boot mode for restoring firmware or settings when the firewall won't boot normally.

📚 Sources

  1. SonicWall — Using Packet Monitor in SonicOS 7 (capture, filters, mirror, pcap export). sonicwall.com/support/technical-documentation
  2. SonicWall — Investigate ▸ Logs: the Event/Log Monitor, categories, filters and levels. sonicwall.com/support
  3. SonicWall — Active Connections Monitor (the Connections table). sonicwall.com/support
  4. SonicWall — System ▸ Diagnostics: ping, DNS lookup, reverse-DNS, traceroute and tools. sonicwall.com/support
  5. SonicWall — How to generate a Tech Support Report (TSR). sonicwall.com/support/knowledge-base
  6. SonicWall — Configuring inbound NAT policies and access rules to publish a server. sonicwall.com/support/knowledge-base

What's next?

Comfortable finding the drop? Next, turn it into interview gold: the most-asked SonicWall interview questions with model answers — zones, NAT, access rules, DPI and the exact troubleshooting story to tell.

Next · All interview lessons → Practice on exam.techclick.in →