TTechclick All lessons
Palo Alto · Troubleshooting · PCAP MasteryInteractive · L2 / L3

PCAP & Packet Diagnostics — Capture at the Right Stage

Every Palo Alto firewall exposes four capture taps: RX, FW, TX, DROP. Picking the right one is the difference between a 5-minute fix and a 5-hour mystery. 13 minutes from "where do I capture?" to "I have proof of where the packet died."

📅 2026-05-25 · ⏱ 13 min · 3 interactive widgets · 🏷 10-Q assessment + AI Tutor inline

Pick where to start

1

4 Capture Stages

RX, FW, TX, DROP — where each tap sits in the dataplane.

 2

5-Step Workflow

Filter → enable → capture → reproduce → cleanup. The exact CLI.

 3

Stage Picker

Symptom → which stages to enable. Decision tree.

 4

Mgmt tcpdump

Mgmt-plane is a different world — different command, different file.

The mental model — packet-diag taps the dataplane in four places

Every packet on a Palo Alto firewall travels through a pipeline: NIC ingress → route/zone/policy lookup → NAT translation → forwarding → NIC egress. The packet-diag framework lets you copy a packet INTO a pcap file at four specific points along that journey. You don't capture "everywhere" — you choose the stage(s) that prove or disprove your hypothesis.

Sneha at Infosys gets a ticket: "SAP server isn't reachable." Step one isn't to capture all four stages — it's to ask "where do I expect the packet?" If she thinks the firewall isn't even receiving the packets, capture rx. If she suspects a policy drop, capture drop. The smaller the capture footprint, the faster the diagnosis and the less disk pressure on the firewall.

① The four capture stages — animated

Watch a packet flow through the dataplane. Each stage's tap is shown in order. Combination of which stages have packets and which don't tells you exactly where the drop happened.

▶ Packet journey through the dataplane

Aditya at Wipro captures all four stages. Watch what each one sees.

① RX (receive) Packet arrives at the NIC. The dataplane has just received it — no policy, no NAT, no zone classification yet. This is the closest tap to the wire. Pre-NAT.
▼
② FW (firewall) Route lookup, zone derivation, security-policy match, NAT match, session install — all done. The packet's about to be transformed. Post-policy (where decisions happen).
▼
③ TX (transmit) Packet has been NAT'd, App-ID'd, profile-scanned. It's now headed to the egress NIC. This is the post-transformation view — the "final state." Post-NAT.
▼
④ DROP (drop) Any packet the dataplane chose to discard at ANY stage gets a copy here. Combine with show counter global filter severity drop delta yes to learn WHY.
Press Play to see each stage's role. Each press of Next advances one stage.
Pattern seenWhat it tells you
RX empty, all others emptyPacket never arrived. Check upstream switch, cable, ARP, source-side firewall.
RX has packets, others emptyPacket arrived but never made it past dataplane. Check route, zone protection, very early drops (Zone Protection counters).
RX + FW have packets, TX empty, DROP populatedFirewall lookup happened, packet got dropped post-policy. Run show counter global right now — counter names which stage.
RX + FW + TX all have packetsFirewall is forwarding successfully. Problem is downstream (server, client, return path).
RX has packets, DROP populated (no FW, no TX)Pre-policy drop. Zone Protection / Bad-checksum / packet-parse error.
Quick check · Q1 of 10

Sneha runs a four-stage capture. She sees: RX has 24 packets, FW empty, TX empty, DROP has 24 packets. What's happening?

Correct: a. All 24 packets arrived at RX, and all 24 ended up in DROP — with nothing in FW or TX. That means the dataplane dropped them BEFORE policy lookup. Common causes: Zone Protection profile (e.g. fragmentation, malformed packet, spoofed IP), NIC offload bug (corrupt checksum), or pre-policy filtering. The counter tells you which specific cause. This is a classic pattern that confuses L1 engineers because the firewall HAS the packet — it just kills it early.

② The 5-step CLI workflow

The exact sequence every PA engineer must memorise. Skip a step and you'll either capture the entire firewall's traffic (disk fills in seconds) or miss the actual packets you wanted.

▶ Rahul at TCS — full 5-step workflow

From "I need a capture" to "I have a pcap on my laptop."

① FILTER FIRST set filter match source 10.10.10.5 destination 8.8.8.8 destination-port 443 then set filter on. Always filter first. An unfiltered capture on a 10 Gbps firewall fills the 200 MB pcap in seconds.
▼
② ENABLE PER-STAGE FILES set capture stage receive file rx.pcap
set capture stage firewall file fw.pcap
set capture stage transmit file tx.pcap
set capture stage drop file dp.pcap
▼
③ ARM set capture on — now packets matching the filter get copied to the relevant stage's pcap.
▼
④ REPRODUCE + WATCH Generate the traffic from the user side. Watch counters with show counter global filter packet-filter yes delta yes — only counters that touched filtered packets appear.
▼
⑤ CLEANUP — DON'T FORGET set capture off
set filter off
clear all
Then SCP: scp export filter-pcap from rx.pcap to admin@10.0.0.50:/captures/
Press Play to walk Rahul's full workflow.
Full CLI — copy this entire block, edit the filter, run as-is 
! Step 1 — Filter FIRST (always)
debug dataplane packet-diag set filter match source 10.10.10.5 destination 8.8.8.8 destination-port 443
debug dataplane packet-diag set filter on

! Step 2 — Per-stage files
debug dataplane packet-diag set capture stage receive  file rx.pcap
debug dataplane packet-diag set capture stage firewall file fw.pcap
debug dataplane packet-diag set capture stage transmit file tx.pcap
debug dataplane packet-diag set capture stage drop     file dp.pcap

! Step 3 — Arm
debug dataplane packet-diag set capture on

! Step 4 — Reproduce traffic from the user side (2-3 attempts is enough)
! Then check counters
show counter global filter packet-filter yes delta yes

! Step 5 — Cleanup (DO NOT skip)
debug dataplane packet-diag set capture off
debug dataplane packet-diag set filter off
debug dataplane packet-diag clear all

! SCP the files out
scp export filter-pcap from rx.pcap to admin@10.0.0.50:/captures/rx.pcap
scp export filter-pcap from fw.pcap to admin@10.0.0.50:/captures/fw.pcap
scp export filter-pcap from tx.pcap to admin@10.0.0.50:/captures/tx.pcap
scp export filter-pcap from dp.pcap to admin@10.0.0.50:/captures/dp.pcap
200 MB file limit + rotation

PAN-OS rotates each pcap at 200 MB — rx.pcap → rx.pcap.1, and keeps a total of ~400 MB per stage. Anything older is overwritten. On a busy firewall, an unfiltered capture can roll those buffers in <30 seconds, meaning you LOSE the packets you wanted. Filter first, capture short windows, retrieve immediately.

Quick check · Q2 of 10

Priya runs set capture on but forgets to run set filter on first. What happens?

Correct: b. Without an active filter, the capture stage is wide open. Every packet matching the stage definition gets copied. The 200 MB ring buffers cycle rapidly, your target packets get overwritten, and you've created I/O contention with the dataplane. Always: set filter match + set filter on BEFORE set capture on. Memorize the order: filter, capture.

③ Stage picker — which to capture when?

You don't always need all four. Pick a symptom; the widget shows which stage(s) prove or disprove your hypothesis.

▶ Symptom → which stages to enable

Karthik at Flipkart picks his symptom — gets the minimum-viable capture plan.

① SYMPTOM Pick a symptom above, then press Play.
▼
② STAGES TO ENABLE —
▼
③ FILTER —
▼
④ INTERPRETATION —
Pick a symptom, then press Play.

Common gotchas — flip cards

⚙
Offload kills captures
tap

Once App-ID completes, sessions offload to hardware. Subsequent packets skip dataplane → no capture. Briefly set session offload no if you need ALL packets — re-enable immediately.

🎯
Pre-NAT vs post-NAT
tap

RX sees the PRE-NAT addresses (what arrived). TX sees POST-NAT (what's leaving). Filter using pre-NAT IPs; if needed for tricky NAT cases, add pre-parse-match yes to the filter set.

💾
200 MB cap
tap

Each pcap rotates at 200 MB; total ~400 MB per stage. Filter tight or your target packets get overwritten. Retrieve immediately after capture-off.

🔒
IPSec / tunnel
tap

For IPSec captures filter by ingress-interface tunnel.10 or filter the ESP outer-headers by source/dest of the tunnel peers. Inside-tunnel packets visible at FW stage after de-encapsulation.

Quick check · Q3 of 10

Aditya needs to capture EVERY packet of a TCP flow that's been ACTIVE for 30 seconds. He sees only 4 packets in his RX file. What's the most likely reason?

Correct: c. SP3 architecture offloads sessions to hardware after App-ID completes. Offloaded packets skip the dataplane, so packet-diag never sees them. You'll catch the first few (slowpath) packets, then silence. Briefly disable offload during the capture window, but understand the impact: ALL sessions on the firewall stop offloading. Schedule for off-hours if it'll run > 30s.

The "no transmit, no drop" mystery — a real war story

From a real Live Community thread (#422829): an engineer captures all four stages on a flow that "isn't working." RX has packets, TX is empty, DROP is empty, traffic log shows action=allow. Confusion peaks.

Solution? The session offloaded mid-flow. The first ~4 packets came through RX + FW + TX normally (verified post-mortem in the rotating pcap.1 file). The next 2000 packets offloaded to hardware and bypassed the dataplane — so they appear nowhere in the four-stage capture. The session was actually working perfectly. The capture's silence was the offload doing its job.

If 4-stage capture is silent — check session offload

show session id <N> → if you see offloaded: yes, that's why your capture is empty. Either accept the offload (the firewall is doing its job efficiently) or briefly disable offload to capture. Don't keep digging assuming the firewall is broken — it isn't.

④ Mgmt-plane tcpdump — a completely different tool

The dataplane packet-diag does not see mgmt-plane traffic. SSH to the firewall, Panorama heartbeats, syslog egress, SNMP polls, the Web UI — these all ride the management plane and need a different command: tcpdump.

Mgmt-plane capture — for Panorama, SSH-to-mgmt, syslog, SNMP 
! Filter using BPF-like syntax
tcpdump filter "host 10.0.0.5 and port 3978"

! Or capture all mgmt SSH + HTTPS
tcpdump filter "tcp port 22 or tcp port 443"

! Stop with Ctrl-C, then view briefly:
view-pcap mgmt-pcap mgmt.pcap

! Then SCP out:
scp export mgmt-pcap from mgmt.pcap to admin@10.0.0.50:/tmp/mgmt.pcap

Mgmt tcpdump always writes to mgmt.pcap (overwritten each run). Max size is ~20 MB. Use it for:

Don't confuse dataplane and mgmt-plane

Karthik wasted 2 hours trying to debug Panorama push failures with packet-diag — finding zero packets. Of course: Panorama control rides the mgmt-plane. tcpdump filter "host <panorama-ip>" solved it in 2 minutes. Always ask: does this traffic touch the dataplane (user data) or the mgmt-plane (administration)? Pick the right tool.

Quick check · Q4 of 10

Karthik suspects Panorama isn't getting heartbeats from the firewall. He runs debug dataplane packet-diag with a filter on the Panorama IP. The capture is empty. Why?

Correct: a. packet-diag taps the dataplane. Panorama control traffic (port 3978/28443/etc) terminates on the mgmt plane and never crosses the dataplane. Use tcpdump filter "host 10.10.10.50" from the firewall CLI to capture. The mgmt-plane is a completely separate world with its own tool, its own pcap file (mgmt.pcap), and its own size limits.

⑤ Retrieving the pcap files

Two ways:

  1. GUI: Monitor → Packet Captures → click each file. Good for one-offs.
  2. CLI / SCP: scp export filter-pcap from rx.pcap to user@host:/path/. Scales to automation.

Files sit on the firewall's filesystem under /var/tmp/. They survive a set filter off but get cleared by debug dataplane packet-diag clear all — so always retrieve BEFORE you clear.

What to look for in Wireshark after retrieval

Pattern in the pcapWhat it tells you
RX has SYN, TX has nothingPolicy/zone/route killed the packet. Check drop pcap + global counters.
RX has SYN, TX has SYN, no SYN-ACK in RXServer unreachable or asymmetric return. Firewall is fine — chase downstream.
Multiple duplicate SYNs from clientClient is retrying because no SYN-ACK. Confirm server is up.
RX shows pre-NAT IP; TX shows post-NAT IPNAT is working as expected. Match against the NAT policy you wrote.
RX packets are truncated (e.g. only first 64 bytes)You hit the snaplen default. Raise capture snaplen if needed for deeper inspection.
Some packets in DROP, marked with bad TCP checksumNIC hardware offload bug (common in VM-Series with TSO/GRO on hypervisor) — disable offload on hypervisor side.

🤖 Ask the AI Tutor

Tap any question — instant answer.

Answers drawn from PAN-OS docs + Live Community real threads.

📝 Wrap-up — six more

4 inline done. 6 to go. 70% (7/10) marks the lesson complete.

Q5 · Apply

Sneha sees: RX has packets, FW has packets, TX has packets — but Wireshark shows the TX packets all have a different source IP than the RX packets. What does this prove?

Correct: b. RX taps BEFORE NAT translation, TX taps AFTER. The diff between RX source IP and TX source IP is the NAT translation in action. This is actually a great proof-of-NAT for documentation or audit purposes. If the IPs were the same, either no NAT rule fired or NAT bypass (no-NAT) was applied — match that against your NAT policy.
Q6 · Analyze

Aditya completes a capture and runs set filter off. Then forgets clear all. He starts a new capture with a new filter. Why might his new capture be wrong?

Correct: c. Old pcap files persist on disk. When you start a new capture with the same filenames, packets append. After multiple runs without clear all, Wireshark shows a confused mix. Always end every capture session with set capture off, set filter off, clear all — in that order.
Q7 · Analyze

Priya needs to debug a GlobalProtect portal connection issue. The client can't even reach the portal page. Where should she capture?

Correct: c. GlobalProtect portal is hybrid. The TCP SYN from the client crosses the firewall's data interface (dataplane), but the actual HTTPS termination for the portal page might be on mgmt-plane depending on config. Capture both stages: data-plane proves the packet arrived at the firewall, mgmt-plane proves the GP service responded. Compare both to isolate where it died.
Q8 · Analyze

Rahul looks at his TX pcap in Wireshark. He sees only every 5th packet from the original flow. Other packets in the flow simply aren't there. What's the most likely cause?

Correct: b. Partial capture of a session is the classic offload fingerprint. The dataplane sees the slowpath packets (App-ID, threat re-inspection, occasional re-evaluation) but offloaded packets bypass it entirely. If you NEED every packet (for vendor TAC or deep protocol analysis), set session offload no briefly during the test. Schedule for off-hours — global offload-off saturates CPU.
Q9 · Evaluate

Karthik is asked: "what's the safest way to capture 100% of the packets in a specific live flow for vendor TAC?" Pick the most professional answer.

Correct: d. Professional approach is: scoped filter, all stages, brief offload-off window with maintenance approval, document the window, capture, clean up. (a) is reckless — offload-off during peak can saturate CPU. (b) wastes uptime. (c) leaves the firewall vulnerable to disk-fill. Real engineering means treating diagnostic actions with the same change-management rigor as configuration changes.
Q10 · Evaluate

After a capture, Aditya opens rx.pcap in Wireshark. He sees the packets, but the first 14 bytes of each packet's Ethernet header look truncated/garbled. Other engineers say "that's normal." Is it?

Correct: b. Palo Alto inserts internal metadata into the L2 header of captured packets — Wireshark may flag it as malformed or odd, but the IP / TCP / UDP layers above are intact and analyzable. This is documented behavior. As long as your L3/L4 data is readable, you're fine. Don't waste time on the L2 metadata cosmetic issue.
Lesson complete — saved to your profile.
Almost! You need 70% (7 of 10) — re-read the section that tripped you up and tap "Try again".

📚 Sources

  1. Palo Alto KB — Getting Started: Packet Capture. knowledgebase.paloaltonetworks.com
  2. LIVECommunity — Flow Basic Debugging tips & tricks. live.paloaltonetworks.com
  3. LIVECommunity #422829 — No transmit/drop in capture (real war story). live.paloaltonetworks.com
  4. Palo Alto KB — Disabling Session Offload to Record Traffic. knowledgebase.paloaltonetworks.com
  5. Palo Alto KB — 200 MB packet capture file limit. knowledgebase.paloaltonetworks.com
  6. Palo Alto Docs — Take a Packet Capture on the Management Interface. docs.paloaltonetworks.com
  7. theworldsgonemad.net — Palo Packet Captures field guide. theworldsgonemad.net
  8. LIVECommunity — Packet capture filters via CLI debug. live.paloaltonetworks.com

What's next?

You now own the troubleshooting trio. Next blog turns to operational failure patterns — HA flapping, commit failures, dataplane CPU spikes, log-forwarding silently dropping. The patterns TAC sees every day, in your toolkit.

Blog 18 · Operational Failures → ← Recap Session Flow