UDP Scan Says Filtered: Is Your WireGuard Peer Actually Down?

Scanners print open or filtered for a UDP port, and the conclusion usually follows within seconds: the tunnel is broken. It might be, but the scan did not establish that. UDP carries no connection handshake, and WireGuard answers nothing it cannot authenticate, so silence is the expected reply to most probes.

Work from the client outwards instead, and treat the scan as one weak data point among several.

What the scanner can and cannot see

A UDP scanner sends a payload and waits. If an ICMP port-unreachable comes back, it can report the port as closed. If nothing comes back, the result is ambiguous by design: a filtered path, an absent host and a running service that ignored the payload all produce the same silence. Three different states, one output string.

WireGuard makes that ambiguity worse on purpose. The protocol accepts a packet only when it authenticates, so a probe with the wrong keys is discarded without a reply. There is no banner, no version string and no error message to fingerprint.

A TCP test on the same port number tests nothing related. It exercises a different listener that may not exist, and its refusal says nothing about UDP.

Open filtered states therefore describe the scanner's uncertainty more accurately than they describe your server.

Walk the real client from the profile inwards

Start with the client's own view. Does the interface hold an address, does the configuration name the right endpoint, and does the handshake counter move when a connection is attempted? A client that never sent a packet and a client whose packets were dropped look identical in a status window. Only the counters distinguish them, so read the counters first.

Then watch the server side while one authorised attempt happens, rather than running a separate scan from a third location:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

The first command reports the last handshake per peer, which is direct evidence that an authenticated exchange completed. The second shows whether packets for the listener arrive at all, which separates a path problem from a configuration problem in one step.

If the capture shows nothing, the packet never reached the host and the tunnel configuration is not the suspect. If it shows arriving packets from the expected address while the handshake stays at zero, the keys or the peer's allowed addresses are the next place to look.

Correlate at the server when you administer it

Confirm that the listener exists and that the provider's firewall permits the UDP port. A host firewall rule and a cloud security group are two independent gates, and either one can drop a packet that the other allowed. Check both against the actual port in the configuration rather than the port you remember.

The address matters as much as the port. A server listening on a specific address will not answer a packet that arrives on another one, and a multi-homed host can receive the probe on the interface you did not intend.

Keep every test inside systems you are authorised to test. The useful comparison is between one real client attempt and the expected server path, not a wider sweep of addresses that happen to belong to the same provider.

Reading a scan result honestly

A scan is a cheap way to check that a host exists and that a port is not obviously blocked by an intermediate device. It is not a reachability proof for an authenticated protocol, and it is certainly not a configuration test.

The stronger evidence is a completed handshake from the client you actually care about, followed by a request that uses the tunnel and gets a response. That sequence exercises the keys, the allowed addresses, both firewalls and the return path in one go.

Where the real attempt fails, the failure still has to be diagnosed with the client's counters and the server's capture rather than with another probe. The protocol description explains why an unauthenticated packet receives no answer, which is the whole reason the scan result is ambiguous.