nmap marks a UDP port as open|filtered when it receives no response to its probe — which is ambiguous. Silence could mean the port is open (service doesn't reply to unexpected packets), the packet was dropped by a firewall (filtered), or the packet was lost in transit. nmap uses protocol-specific probes to resolve this: if it knows the protocol on a given port (e.g. DNS on 53), it sends a valid protocol request. If that gets a real DNS response, the port is definitively "open". Without a protocol-specific probe, UDP ports remain ambiguous. Use sudo nmap -sU -sV -p <ports> target for the most accurate UDP scan.

Web browsers run JavaScript in a sandboxed environment that cannot create raw network sockets. JavaScript's networking is limited to: HTTP/HTTPS fetch requests, WebSockets (TCP-based), and WebRTC (which can use UDP but only through the WebRTC API, not arbitrary UDP). This is a deliberate security boundary — raw socket access would let any website perform port scanning, send spoofed packets, or participate in DDoS attacks. This is why browser-based UDP testing must use indirect methods: DNS tests use DNS-over-HTTPS (HTTP), NTP tests use HTTP time APIs, and WireGuard cannot be tested at all from a browser. For true UDP testing use nmap, netcat (nc -u), or dig.

One-way audio means SIP signalling (port 5060) is working but RTP media (UDP 16384–32767) is blocked or misconfigured. Check: (1) Your firewall/router is forwarding UDP 16384–32767 to the SIP device or PBX. (2) SIP ALG is disabled on your router — SIP ALG (Application Layer Gateway) modifies SIP/SDP packets and often breaks NAT traversal, causing private IPs to appear in the SDP instead of the public IP. (3) Your PBX/SIP proxy is configured with STUN or a public IP for the SDP media line. (4) Your firewall stateful inspection is treating UDP RTP as established flows. The most common fix: disable SIP ALG and configure STUN.

An open resolver answers DNS queries from any IP, not just your own clients. To test: dig @your-dns-server-ip google.com — if it returns an answer from a machine that should only serve your internal network, it's an open resolver and can be abused for DNS amplification attacks. Fix in BIND: set allow-recursion { your-network; }; in named.conf. Fix in Unbound: set access-control: 192.168.0.0/16 allow. Fix at firewall: block port 53 UDP/TCP inbound from all IPs except your clients. You can also test your server at openresolver.com or with the OpenResolver Project.

Corporate firewalls and network inspection appliances are designed around TCP. UDP/443 traffic carrying QUIC is encrypted and looks like random data to a DPI (Deep Packet Inspection) firewall — it cannot inspect the contents. Some enterprise firewalls block UDP/443 to force all HTTPS traffic over TCP/443 where it can be inspected via SSL inspection proxies. The result: QUIC connections fail and browsers fall back to HTTP/2 over TCP. In highly controlled corporate environments and some government networks in India, UDP/443 may be blocked as policy. Servers can detect this using the Alt-Svc and Accept-CH headers.

STUN (Session Traversal Utilities for NAT) is a discovery protocol — it helps a device behind NAT discover its public IP and port mapping. The STUN server on port 3478 UDP simply reflects the source IP and port back to the client. This works for most NAT types (full cone, restricted cone) but fails with symmetric NAT (used by many corporate firewalls). TURN (Traversal Using Relays around NAT) is a relay server — when STUN fails, media is relayed through the TURN server. TURN always works but adds latency and server bandwidth cost. WebRTC uses ICE (Interactive Connectivity Establishment) to try direct connection first (no STUN/TURN), then STUN, then TURN as fallback.

The critical difference is how they handle unauthenticated connections. OpenVPN sends an error response to any connection attempt — so a port probe can confirm OpenVPN is running on that port. WireGuard silently drops all unauthenticated packets and never responds — making it completely invisible to port scanners. This is a deliberate security design called "stealth mode" — an attacker cannot confirm WireGuard is running, cannot fingerprint the VPN software, and cannot begin any attack without valid credentials. The downside: you cannot verify WireGuard is working from a port test — you must attempt an actual authenticated VPN connection.