Packets that never return
Advanced packet capture with tcpdump, and how to find where packets die on a VyOS network: missing NAT and return routes, asymmetric routing through a stateful firewall, and MTU black holes, all diagnosed on a real VyOS router.
By the end you will be able to:
- Find where packets disappear by capturing at several points and bisecting the path
- Use tcpdump fluently: interface choice, -e/-v/-A, pcap files, ring buffers and BPF filters on flags and ICMP types
- Troubleshoot with VyOS's monitor traffic, NAT and firewall commands, and the nftables underneath
- Recognise and fix missing NAT and missing return routes
- Explain why asymmetric routing breaks stateful firewalls, and prove it with captures and counters
- Diagnose an MTU black hole and fix it with ICMP policy or MSS clamping
Prerequisites: Linux Network Connectivity
The hardest problems to troubleshoot look like this: the request goes out, and nothing comes back. No error, no reset, just silence. Ping shows 100% loss, TCP connections time out, a download stalls halfway.
Silence is ambiguous. The request might have been dropped on the way out, or it arrived and the reply was dropped on the way back, possibly on a completely different path. Guessing from the endpoints doesn't work. Packet captures at several points along the path do.
The method:
- Capture at the source. Did the request leave, with the source address and next-hop MAC you expect?
- Capture where you suspect trouble. Usually both sides of a router or firewall.
- Capture at the destination. Did it arrive? Did a reply leave? Toward which next hop?
- Bisect. The fault lies between the last point that saw the packet and the first that didn't.
A capture tells you what happened on the wire. The router's tables (routes, NAT translations, conntrack, firewall counters) tell you why.
This lesson uses a lab with a real VyOS router (rolling release 2026.10.16) between a LAN and a WAN, plus a second Linux router, rtr2, that we use to create trouble. Every output in this lesson was captured from it.
- 1. At the source. tcpdump on the client: did the request actually leave, from the address and to the MAC you expect? If not, the problem is local (route, ARP, firewall).
- 2. Router, inside interface. monitor traffic on R1 eth0: did it reach the router? If the client sent it but R1 never saw it, look at the LAN (VLAN, ARP, wrong gateway).
- 3. Router, outside interface. monitor traffic on R1 eth1: did it leave, and with which source address? This is where you spot missing NAT or a policy drop inside the router.
- 4. At the destination. tcpdump on the server: did it arrive, did a reply leave, and toward which MAC (-e)? A reply leaving toward an unexpected router is asymmetric routing.
- 5. Follow the reply back. Repeat in reverse. The fault is between the last point where you saw the packet and the first where you didn't. Each capture halves the search space.
Check your understanding
The client's capture shows SYNs leaving, and the server's capture shows them arriving. The client never gets a SYN-ACK. Where is the fault?
- On the client, because that's where the symptom is
- Somewhere on the return path: at the server or between it and the client
- On the forward path between client and server
- In DNS