Port / UDP
1194OpenVPN
OpenVPN's default port for tunnelled, TLS-authenticated site-to-site and remote-access VPN traffic.
If it is internet-facing: Port 1194 is legitimate in the right place, but exposed carelessly it widens the attack surface noticeably.
Exposure
Internet-facing
Transport
Encrypted by default
Risk if public
Elevated
Exposure verdict
Port 1194 is meant to answer from the internet, and it protects the session itself. What remains is authentication strength, patch level, and rate limiting.
The session is protected from the first byte, so there is no plaintext phase for an on-path attacker to strip or read.
Registered with IANA on request, but bindable by any unprivileged user. Registration records intent — it does not reserve the port, so collisions between products are common.
Grouped with the other network services ports so a rule written for one can be checked against its neighbours.
What actually goes wrong
2 notes- This is a port meant to be public; the security lives in certificate-based authentication and tls-auth/tls-crypt.
- tls-crypt hides the handshake, so scanners cannot confirm a VPN is listening at all.
Recommended firewall rule
Allow it, and harden the service
This port is expected to answer from anywhere, so the firewall is not where its security comes from.
ufw
sudo ufw allow 1194/udpiptables
sudo iptables -A INPUT -p udp --dport 1194 -j ACCEPTCheck what is really there
Listening locally
sudo ss -ulpn 'sport = :1194'The bind address is the answer that matters: 127.0.0.1 is local-only, 0.0.0.0 and :: mean every interface.
Listening (macOS)
sudo lsof -nP -iUDP:1194macOS ships lsof rather than ss; this names the owning process and user.
From outside
nmap -sUV -Pn -p 1194 <host>A version probe confirms whether OpenVPN is actually what answers, rather than trusting the number. Only scan hosts you are authorised to test.
Reachability
nc -vzu <host> 1194The quick yes/no when you only need to know whether a path exists through the firewall.