Port 1194 OpenVPN – Free, Online, Private

What listens on 1194

Port 1194 is OpenVPN. The IANA name is openvpn, assigned in 2004, for both UDP and TCP. The daemon's proto directive picks one. A server in UDP mode does not answer a TCP handshake on 1194, and the reverse is also true. The default in the upstream sample config is UDP. The peer is authenticated with a certificate, a TLS key, or a shared secret, depending on the generation of the config. The tunnel then carries IP packets. WireGuard is a different protocol and is not this port. IPsec is not this port either.

The IANA service name is openvpn: OpenVPN. The practical transport is TCP and UDP. The checks below include both TCP and UDP, because both transports matter for this service. A process can bind this port without being the service in the registry. The commands show who bound it. They do not prove the protocol on the wire is the one IANA named.

Service notes for port 1194

Service notes for port 1194: the IANA name is openvpn (OpenVPN), and the program people mean is OpenVPN. Port 1194 is the IANA openvpn port, on UDP and TCP. The usual deployment is UDP. TCP is a fallback for networks that block UDP. An OpenVPN port on the internet is supposed to be there if this host is a VPN server. The security is the authentication and the TLS settings, not the secrecy of the port number. Old configs with small DH parameters or with comp-lzo should be retired. A server that does not check client certificates, and relies on a static key everyone has, is one leak away from a full peer. Split the admin SSH access from the VPN port. Do not run the daemon as a user that can read the whole disk. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 1194, you are on the wrong page.

The common outage is a client with proto tcp and a server with proto udp. Both ends show the process running and neither passes traffic. A second is a cloud security group that allows UDP 1194 and a local firewall that allows TCP 1194. A third is NAT. UDP needs a consistent mapping, and a middlebox that times out the mapping makes the tunnel flap. TCP mode survives more middleboxes and then collapses under retransmission when the tunnel itself carries TCP. A fourth is a redirect-gateway push that black-holes the client because the server has no NAT for the VPN subnet.

How to check whether it is open

On the machine itself, ask the kernel which socket is bound. ss and lsof do that. A firewall, a security group, and a Docker publish rule sit in front of that socket, so a listener is not the same thing as a port the internet can use. From somewhere else, nc -vz host 1194 tries a TCP handshake when the command is the TCP form. A refusal means something answered with a reset. A timeout means a filter dropped the packet or the host is unreachable. Those are different faults. Match the transport to the config. ss shows a UDP socket or a TCP LISTEN, not both, unless you actually run two daemons. A remote TCP probe is meaningful only for proto tcp. For UDP, a packet capture or the daemon log is the test. nc -vzu does not complete a VPN handshake.

grep and findstr match text. A pattern of :80 also matches :8080 and :8000. The lsof and Get-NetTCPConnection forms take a numeric port and do not have that substring bug. Use them when the number is ambiguous. ss filters in the kernel with sport = :N, which is also exact. On macOS, netstat -p selects a protocol. It does not print the process the way Linux netstat -p does. lsof prints the process.

• UDP and TCP are different OpenVPN modes. The client and server must agree.
• 1194 is not WireGuard and not IPsec.
• A listening socket is not a completed tunnel. Authentication can still fail.
• Changing the port in the server config without changing the client config looks like a firewall drop.

Linuxsudo ss -lpun 'sport = :1194'
sudo lsof -nP -iUDP:1194
sudo ss -lptn 'sport = :1194'
sudo lsof -nP -iTCP:1194 -sTCP:LISTEN

macOSsudo lsof -nP -iUDP:1194
netstat -anv -p udp | grep '\.1194[^0-9]'
sudo lsof -nP -iTCP:1194 -sTCP:LISTEN
netstat -anv -p tcp | grep '\.1194[^0-9]'

Windowsnetstat -ano | findstr :1194
Get-NetUDPEndpoint -LocalPort 1194
Get-NetTCPConnection -LocalPort 1194

Remotenc -vzu host 1194
nc -vz host 1194