UDP VPN Silent on a Port Scan? Why That Happens
WireGuard and hardened OpenVPN drop datagrams that fail authentication without replying. Silence from a scanner is expected behaviour, not a closed port.
You scan the VPN port, get no reply, and conclude the service is down or the firewall is closed. With WireGuard, and with OpenVPN control channels that carry their own authentication, that conclusion does not follow. A datagram without valid authentication material is discarded without a response, so silence is what a healthy service looks like from the outside. The probe is wrong before the tunnel is.
Silence is the protocol, not a fault
UDP has no connection setup, so there is no SYN and no acknowledgement that would let a scanner tell an open port from a filtered one. A probe arrives as an isolated datagram, and the service checks whether it matches the protocol it expects. When it does not, the packet is dropped, and dropping is the documented behaviour rather than a malfunction.
WireGuard validates its handshake messages cryptographically and ignores anything that fails. OpenVPN with tls-auth or tls-crypt does the same for its control channel. In both cases an arbitrary payload never reaches a user-facing stage, so there is nothing to reply with and no error to return.
TCP would have given you a reset from a closed port. UDP leaves you with ambiguity, which scanners resolve by printing open or filtered instead of guessing.
What a scanner can and cannot conclude
A scan result is only as informative as the payload it sent. Sort the possible observations by what each one actually supports:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
Read the third row as the only positive test in the list. It requires the real profile, the real key and the right endpoint, which is exactly what a generic scanner does not have.
Look at both ends of the path
For a server you administer, capture on the interface before drawing any conclusion, then ask the service what it saw. Both commands need root on the gateway:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showIf no packet appears at the interface, the path dropped it before the service saw anything, and the next stop is routing and filtering. If packets arrive but no handshake completes, the service is reachable and the mismatch is in keys, endpoint configuration or protocol version. That comparison answers the question the scanner could not. Run it while a real client attempts to connect, not while the scanner repeats itself.
Change the test, not the protection
The tempting shortcut is to disable control-channel protection so a diagnostic gets a reply. That trades a real security property for a nicer-looking scan result, and it is the wrong direction. Use a valid profile from an approved network instead, and note the endpoint and time so the comparison is repeatable.
The most useful test is a differential one: the same profile on a path that works and on the path that does not. If the working path produces a handshake and the failing path produces nothing at the interface, you have located the break without weakening anything.
An unanswered UDP packet therefore proves neither that the server is offline nor that it is safe. It proves that this probe, on this path, at this moment, was not accepted.