Find dropped VPN packets without capturing their contents

A firewall counter increments when a packet matches a rule, and it does that without keeping the packet. That is enough to answer the first question in most drop investigations: did the flow reach this rule at all. Payload capture answers a different question, and it collects whatever else crosses the interface while it runs. Start with the counter, and move to metadata logging only when the counter is ambiguous.

Counters answer the first question

Every rule that can match has a counter, and reading it before and after a test tells you whether traffic arrived. That is a two-number comparison rather than an archive, and it costs nothing in storage or exposure.

Read the counters with the tool that owns the rules:

iptables -L FORWARD -v -n --line-numbers
nft list ruleset

The delta is the evidence. A rule whose counter does not move never saw the flow, which points at an earlier boundary: the wrong interface, the wrong table, or a route that never sent the packet there. A rule whose counter moves and still drops tells you the policy is doing what it was written to do.

What a counter cannot tell you

A counter gives you a number, not a reason. It cannot distinguish a packet that matched on address from one that matched on port, and it cannot tell you which of two similar rules caught the flow. It also cannot tell you whether the packet was dropped, rejected, or accepted and then lost later, unless you read the rule that owns the counter.

That is where metadata logging comes in, and scope is the whole point. Log the interface, direction, addresses, protocol and verdict for a specific test flow. Those fields locate a failed boundary without recording what the user was doing.

Payload logging answers a different question, and it answers it about everyone on the interface.

Metadata logging with a narrow scope

Write a rule that matches only your test flow, give it a distinctive prefix, and rate-limit it under the platform's own controls so an ordinary retry cannot flood storage. The prefix is what lets you find your entries among everything else the device logs.

Avoid enabling payload or unrestricted packet logging because the feature exists. A truncated capture is not automatically payload-free either, since header sizes and packet layouts vary, so a snap length that looks small can still carry application bytes.

If you must capture, capture one flow, for a bounded time, with the smallest snap length that answers your question.

Match one fresh request

Generate harmless traffic that follows the actual client route, then compare the relevant counters before and after. A gateway-local test can miss a forwarding rule entirely, because the packet never takes the forwarding path. An established session can also match different state handling from a new connection, so a long-lived flow is not a substitute for a fresh one.

Time-box the window and write it down. Between two specified minutes, from this client address, to this destination on this protocol is a diagnosis. Sometime this morning is a search.

One flow, one window, one boundary is the unit of progress here.

Clean up and keep only the excerpt

Remove the temporary diagnostic rule through the owning configuration once the investigation ends. A narrow logging rule left in place becomes an unintended record system, and nobody remembers why it exists six months later.

Keep original records privately when policy requires it, and share a reviewed minimal excerpt rather than the whole capture. Addresses, account identifiers and internal topology are sensitive even when no payload is present. Treat the excerpt as a document with an owner. Redact whatever the diagnosis does not need.

The goal is a specific failed boundary for a specific request. Anything that produces a complete archive of everyone using the VPN has exceeded the diagnosis and started a different project. Check the platform's logging documentation for what it records by default before you add anything to it.