Tcpdump and SNAT on Linux NAT Server: Why Outgoing SNAT Packets Don’t Appear in Captures (and How to Fix It)

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.