OpenVPN Connects but Nothing Flows: Find the Drop Layer

OpenVPN says connected and no traffic moves, a sentence that covers at least five unrelated faults. Editing firewall rules before you know which layer is failing multiplies the unknowns and hands the next engineer a mess. Work outward from the process instead, because every step below either clears one stage or narrows where the packet dies. Order matters here: a capture taken before you know which address is bound will prove something, just not the thing you need.

The socket is either bound or it is not

A service reporting active can still be bound to an address or a transport you never intended. Query the socket itself: ss -lunp lists UDP listeners and ss -ltnp lists TCP ones, and the column worth reading is the local address, not the state.

An empty answer usually means one of three things: the process exited after starting, it loaded another configuration file, or it listens on a different address from the one being dialled.

ss -lunp | grep 1194
ss -ltnp | grep 1194

A local directive pins the listener to a single address, so a client aimed elsewhere on the same host is refused while the service still looks healthy from outside. An instance name can also point at a file you never edited, which happens on hosts running two profiles side by side.

Capture the outer packet, not the tunnel

Filter on the physical interface and the real port, with your own interface substituted: tcpdump -ni eth0 udp port 1194. Outbound packets with nothing coming back point at what sits upstream: provider filtering, a NAT device, or a remote address that is not the one you think. Silence in both directions points at client routing or a local firewall. Replies that arrive without tunnel progress point at the control channel, meaning a key or cipher mismatch, not at filtering.

Capture both directions and keep the file short. A long capture buries the interesting three seconds, and the answer almost always sits in the first exchange.

Counters first, trace only when they lie

Start with the counters, because they cost nothing. Either nft list ruleset or iptables -L -n -v answers the only question that matters here: did the rule match? Order decides the outcome, since the first match wins, which is why a broad DROP ahead of a later ACCEPT leaves that ACCEPT dead and why appending a rule so rarely repairs anything.

Ownership trips people up as well. The kernel attributes locally generated packets to whichever process opened the socket, and OpenVPN normally runs as root, so a rule keyed to an ordinary user ID never sees the tunnel's own traffic. Check the owning UID before deciding that the rule is wrong.

Only when the counters stay ambiguous is a log worth the noise, and then only for a narrow slice: an iptables rule that rate-limits and prefixes its log lines, or an nftables rule carrying meta nftrace set 1 with nft monitor trace running. A trace names the chain and the rule that accepted or dropped the packet. Remove both afterwards and keep payload logging out of it.

Check the transport as well. A firewall service scoped to TCP says nothing about a UDP listener on that number, so a rule that reads correctly can still drop every packet.

Routing and the way back

An accepted packet that still vanishes needs its destination path examined. ip route get reports the route chosen for one address, and reverse-path filtering can drop a reply that arrives over an interface the main table would never pick. The symptom looks exactly like a firewall drop, which is why this check comes before another NAT rule.

On a gateway, inspect forwarding and the forward chain rather than the input chain. Then confirm the far side knows how to reach the source address, because a working outbound path with nothing coming back is silence either way.

What the record has to say

For each change, note the stage you tested, the evidence you read and the counter value on both sides of it. That note is what makes "it works now" survivable at the next review.

Two shortcuts keep the note honest. A packet that never left the host cannot have been dropped by a rule somewhere else, however convincing the far-side configuration looks. A packet that left and returned moves the question above the network layer, where firewall counters have nothing left to tell you.