When troubleshooting NAT traffic, many administrators face a confusing scenario — tcpdump doesn’t capture outgoing SNAT (POSTROUTING) packets.
This article explains why that happens, visualizes the packet flow, and shows how to capture post-SNAT packets correctly.
🧩 Understanding the Issue: Why Tcpdump Misses SNAT Packets
The Core Reason
tcpdump captures packets before NAT (SNAT) occurs.
It hooks into the packet path at a point before the POSTROUTING chain.
In other words, tcpdump uses packet capture hooks from the kernel’s AF_PACKET socket layer.
These hooks see packets as they enter or leave a network interface, but not after all iptables nat table processing — especially not after SNAT.
Simplified Packet Flow:
Incoming packets
↓
[PREROUTING] (DNAT) ← tcpdump sees here
↓
Routing / local process
↓
[POSTROUTING] (SNAT) ← tcpdump does NOT see here
↓
Network device
Why SNAT Packets Are Missing in tcpdump Captures
SNAT takes place in the POSTROUTING chain, which modifies packets after they’ve been queued to the output device.
By that time, tcpdump has already captured the packet — showing the pre-SNAT source IP.
So even though the packets are being SNATed and sent out, tcpdump -i any will only display their pre-SNAT form.
✅ Solution: Capturing Outgoing SNAT (POSTROUTING) Packets
Option 1: Use NFLOG (iptables-based logging)
You can explicitly log SNAT traffic using the NFLOG target and then capture it with tcpdump or nflog.
Using the NAT Table (Recommended ✅)
sudo iptables -t nat -A POSTROUTING -j NFLOG --nflog-group 5
Then capture it:
# Option 1
sudo nflog -i 5 -o postrouting.pcap
# Option 2
sudo tcpdump -i nflog:5 -w postrouting_nat.pcap
| Tool | Description |
|---|---|
tcpdump -i nflog:5 -w file | Uses libpcap interface directly — quick for analysis or .pcap capture |
nflog -i 5 -o file | Native Netfilter log reader — good for direct NFLOG dumps (older tool) |
This approach logs packets after SNAT translation, so you’ll see the post-NAT source IP.
Option 2: Tcpdump on Network Interface (❌ Still Misses SNAT)
Even if you try:
sudo tcpdump -i eth0 -n -w out.pcap
You may still not see SNAT packets, because:
- tcpdump hooks into AF_PACKET, before packets reach the NIC driver.
- SNAT occurs very late in the path — after routing, checksum, and queuing.
- Unless you capture below the NAT hook (e.g., with eBPF, XDP, or hardware mirroring), you’ll only get pre-SNAT data.
🧹 How to Remove NFLOG Rule from iptables after captured
Step 1: List Current Rules
sudo iptables -t nat -L POSTROUTING -v --line-numbers
Example Output:
Chain POSTROUTING (policy ACCEPT 0 packets, 0 bytes)
num pkts bytes target prot opt in out source destination
1 0 0 NFLOG all -- any any anywhere anywhere nflog-group 5
2 0 0 SNAT all -- any eth0 anywhere anywhere to:1.2.3.4
Step 2: Delete the Rule
sudo iptables -t nat -D POSTROUTING 1
Step 3: Verify
sudo iptables -t nat -L POSTROUTING -v --line-numbers
Step 4 (Optional): Save Configuration
sudo service iptables save
# or
sudo iptables-save > /etc/sysconfig/iptables
🧠 Summary
| Key Point | Description |
|---|---|
tcpdump sees pre-NAT packets | It hooks into AF_PACKET before POSTROUTING |
| SNAT happens after routing | Hence not visible to tcpdump |
| To see SNAT’d packets | Use NFLOG in the NAT table |
| Mangle table captures pre-SNAT | NAT table captures post-SNAT |
| Regular tcpdump still misses SNAT | Needs NFLOG, eBPF, or hardware mirroring |
🔍 Final Thoughts
Tcpdump is an essential diagnostic tool — but it’s limited by where it hooks into the kernel’s packet path.
When debugging NAT issues, always remember: SNAT occurs after tcpdump’s capture point.
Use NFLOG on the NAT table to view the real, post-SNAT traffic.
With this method, you’ll finally see the true outgoing source IP as it leaves your Linux NAT server.