Port 1194 – OpenVPN

Port 1194 is the default port for OpenVPN, the open-source SSL/TLS VPN that carries most self-hosted remote-access and site-to-site tunnels. By default OpenVPN listens on UDP 1194, but it runs equally well on TCP 1194, and administrators frequently move it to TCP 443 so the traffic blends in with HTTPS and slips past restrictive firewalls. An open 1194 is a clear signal that you’ve found a VPN gateway — a remote-access door straight into an internal network, which makes it one of the higher-value targets on an external engagement. OpenVPN itself is a modern, well-audited protocol; the weakness almost never lives in the crypto and almost always in configuration, authentication, and unpatched client software.

Why It’s Open

OpenVPN is the go-to self-hosted VPN because it’s userspace, cross-platform, and needs only a single UDP or TCP port. You’ll find port 1194 open on cloud instances (AWS/Azure/GCP VPN boxes), pfSense and OPNsense firewalls, home routers and NAS appliances, Docker/Kubernetes VPN sidecars, and dedicated OpenVPN Community or OpenVPN Access Server deployments. It carries both remote-access VPNs (roaming laptops dialing home) and site-to-site links between offices.

OpenVPN is a different technology from the other VPNs you’ll meet on a scan — it’s TLS-over-UDP/TCP, not IPsec. It sits alongside IPsec IKE on port 500 (and its NAT-Traversal partner UDP 4500), L2TP on port 1701, and legacy PPTP on port 1723 in the VPN family, but shares none of their protocol machinery. When an OpenVPN server is deliberately parked on TCP 443 to look like web traffic, a service-version scan of 443 that comes back “OpenVPN” instead of an HTTP server is a dead giveaway.

Common Risks

Because the protocol is sound, the findings on port 1194 cluster around how it’s deployed:

• Weak or stolen VPN credentials. Servers using auth-user-pass without MFA are open to credential spraying and brute-force, and compromised VPN logins are one of the most common ransomware initial-access vectors in real incidents. A stolen .ovpn profile plus a password — or an embedded client key — is often full network access.
• No tls-auth / tls-crypt on the control channel. Without an HMAC (or encryption) wrapper on the control channel, the server answers unauthenticated packets — which makes it fingerprintable, exposes it to pre-auth DoS, and is a precondition for the deferred-auth disclosure below.
• Deferred-authentication information disclosure. Servers wired to an external auth backend (LDAP/RADIUS) with deferred auth can be tricked into leaking control-channel data before the login is rejected — CVE-2020-15078.
• Weak or legacy ciphers. Old configs pinned to BF-CBC, or without modern data-ciphers negotiation, leave the data channel on deprecated crypto.
• Over-broad pushed routes / no split-tunnel discipline. A single compromised client that gets pushed the whole 10.0.0.0/8 reaches far more of the internal network than it should.
• Unpatched clients — especially on Windows. The 2024 interactive-service and TAP-driver bugs are local privilege escalation and code execution on Windows endpoints, not on the server, but a compromised VPN client is still a foothold.

Want to save time on reporting?

Let PentestPad generate, track, and export your reports - automatically.

Book a Demo

Enumeration & Testing

Detect the service on UDP and TCP

# OpenVPN's default is UDP, but it also runs on TCP — check both
nmap -sU -sV -p 1194 <target>
nmap -sT -sV -p 1194 <target>

Check the common OpenVPN-over-HTTPS evasion port

# An OpenVPN server hiding as web traffic answers here, not an HTTP stack
nmap -sT -sV -p 443 <target>

A note on fingerprinting: OpenVPN’s control channel uses a distinctive opcode/session-ID handshake, so a server without tls-auth/tls-crypt will reply to a probe and give itself away (and can be identified by byte-pattern research tooling and Shodan’s product:OpenVPN filter). A server with tls-crypt enabled drops every packet that isn’t HMAC-authenticated, so it looks like a silent UDP port and is very hard to fingerprint — which is exactly why tls-crypt is the first hardening step below.

Test a connection with a captured or provided profile

openvpn --config client.ovpn

Enumerate live sessions if you reach the management interface

# openvpn-monitor (furlongm) is a web UI over the OpenVPN management console —
# useful post-foothold to enumerate connected users, source IPs, and routes
# https://github.com/furlongm/openvpn-monitor

Credential attacks against OpenVPN aren’t a one-line Hydra module: auth-user-pass logins usually validate against a RADIUS or LDAP backend, so spraying is scripted through repeated --auth-user-pass connection attempts (with a valid CA) or aimed at the auth backend itself. Every reachable gateway, missing tls-auth, and valid credential you confirm is a finding — keep it with the engagement so it lands in the pentest report instead of a scratch terminal you’ll lose.

What to Look For

Known CVEs and Exploits

OpenVPN’s CVE history splits cleanly into server-side bugs that touch the daemon on port 1194 and a Windows client-side cluster that never touches the server. Scoping them correctly matters — a critical-scored Windows client bug does not mean you can remotely own a Linux OpenVPN server.

Server-side (the daemon on port 1194):

• CVE-2020-15078 — Authentication bypass and control-channel information disclosure. On servers configured with deferred authentication, a remote, unauthenticated attacker can pull control-channel data (a PUSH_REPLY returned before AUTH_FAILED), and combined with --auth-gen-token or token-based auth it can lead to access with an otherwise-invalid account. Affects OpenVPN ≤ 2.4.10 and 2.5.0–2.5.1. CVSS 7.5 (High), AV:N/AC:L/PR:N/UI:N/C:H/I:N/A:N — server-side, unauthenticated.
• CVE-2017-7508 — Remote, pre-authentication denial of service: a malformed IPv6 packet trips a reachable assertion and crashes the daemon. Affects OpenVPN before 2.4.3 and 2.3.17. CVSS 7.5 (High), AV:N/AC:L/PR:N/UI:N/A:H — hits both server and client, no auth required. From the 2017 Guido Vranken audit.
• CVE-2017-7521 — Remote DoS through memory leaks and a double-free in extract_x509_extension() during certificate parsing in the TLS handshake. Affects OpenVPN before 2.4.3 and 2.3.17. CVSS 5.9 (Medium), AV:N/AC:H/PR:N/UI:N/A:H. (The old version of this page mislabeled this as “memory leak through push-peer-info” — it’s the x509 parser.)
• CVE-2017-7520 — DoS and possible sensitive memory disclosure to a man-in-the-middle attacker (a client connecting through a malicious NTLMv2 HTTP proxy). Affects OpenVPN before 2.4.3 and 2.3.17. CVSS 7.4 (High), AV:N/AC:H/PR:N/UI:N/C:H/I:N/A:H — client-side, requires MITM.
• CVE-2014-8104 — Denial of service (server crash), not RCE. A TLS-authenticated client can crash the server by sending a too-small control-channel packet. Affects OpenVPN 2.x before 2.0.11, all 2.1.x, 2.2.x before 2.2.3, and 2.3.x before 2.3.6. CVSSv2 6.8 (AV:N/AC:L/Au:S/C:N/I:N/A:C) — requires an authenticated user, so it’s a lower-severity server bug than the outdated page implied.

Windows client-side — the 2024 “chained RCE + LPE” cluster (disclosed by Microsoft, Aug 2024; affects OpenVPN 2 on Windows ≤ 2.6.9). These live in the Windows GUI, interactive service, and TAP driver — none is a remote compromise of the Linux/Unix daemon on 1194:

• CVE-2024-27903 — OpenVPN plug-ins on Windows can be loaded from any directory, letting an attacker load an arbitrary plug-in that interacts with the privileged interactive service. CVSS 9.8 (Critical) per NVD — but Windows-client / plugin-loading, chained (not a standalone remote server exploit).
• CVE-2024-1305 — Integer overflow in the tap-windows6 driver (≤ 9.26): unchecked write sizes overflow kernel buffers, causing a bug check and potentially kernel-space code execution. CVSS 9.8 (Critical) — Windows TAP driver, client-side.
• CVE-2024-27459 — Stack overflow in the Windows interactive service enabling local privilege escalation. CVSS 7.8 (High), AV:L — requires local access.
• CVE-2024-24974 — The Windows interactive-service named pipe (\\openvpn\\service) can be reached by an unprivileged local user to drive the privileged service. CVSS 7.5 (High) — Windows client-side.

Scope note: Chained (e.g. CVE-2024-24974 + CVE-2024-27903, or CVE-2024-27459 + CVE-2024-27903), the 2024 bugs give RCE/LPE on a Windows endpoint running the OpenVPN client — a reason to patch every VPN client, not a way to pop the gateway on port 1194 remotely. The previously listed Exploit-DB link (35481) has been removed: it points to an unrelated Newsportal XSS, not any OpenVPN vulnerability.

Mitigation

• Turn on tls-crypt (or at least tls-auth). Wrapping the control channel with an HMAC/encryption key means the server ignores every unauthenticated packet — killing fingerprinting, pre-auth DoS, and CVE-2020-15078 in one move. This is the single highest-value hardening step.
• Use strong client certificates and a real PKI. Issue per-user certs from a properly managed CA, keep them short-lived, and revoke on offboarding.
• Require MFA. Add TOTP/push on top of auth-user-pass, or pair certificate auth with a password. This is what stops the stolen-credential ransomware path.
• Patch the server and the clients. Keep the daemon current for the DoS CVEs above, and push Windows clients past 2.6.9 and tap-windows6 past 9.26 to close the 2024 cluster.
• Drop weak ciphers. Require AES-GCM via data-ciphers, disable BF-CBC and other legacy suites.
• Push least-privilege routes. Only route the subnets a client genuinely needs; segment the network the VPN lands in instead of pushing the whole estate.
• Monitor authentication. Alert on failed-login bursts, impossible-travel logins, and unexpected concurrent sessions — and don’t rely on port obscurity: moving to 443 hides you from casual scans, never from a real assessment.

Real-World Example

CVE-2020-15078 is the cleanest illustration of why an internet-facing 1194 deserves a hard look even when the crypto is solid. On an OpenVPN server using deferred authentication — the common pattern when logins are validated by an external LDAP or RADIUS script — a remote attacker who supplies an invalid account can nudge the server into replying with a PUSH_REPLY (carrying pushed routes and other control-channel data) before it sends the AUTH_FAILED. That leaks details of the VPN’s internal layout to someone who never authenticated, and on servers that also lean on --auth-gen-token for session tokens, the flaw opens a path to access with credentials that should have been rejected outright. No memory corruption, no exploit chain — just the authentication logic handing information to an attacker it was supposed to turn away. It’s the OpenVPN echo of the same lesson port 500’s IKE bugs teach: the service whose job is to gatekeep secrets is exactly the one worth probing.

FAQ

What is port 1194 used for?

Port 1194 is the default port for OpenVPN, an open-source SSL/TLS VPN. It carries the encrypted tunnel for remote-access VPNs (users connecting to a corporate or home network) and site-to-site links between networks.

Is port 1194 TCP or UDP?

Both. OpenVPN’s default is UDP 1194 because UDP performs better for tunneled traffic, but it works just as well on TCP 1194, and it’s very often run on TCP 443 to disguise the tunnel as ordinary HTTPS and get through restrictive firewalls.

Is OpenVPN on port 1194 secure?

The protocol is modern and well-audited, so yes — when it’s configured well. The real risks are operational: weak or stolen credentials without MFA, a missing tls-auth/tls-crypt key on the control channel, legacy ciphers, and unpatched clients. Harden those and an exposed 1194 is reasonably safe; skip them and it’s a soft entry point.

What’s the difference between OpenVPN (1194), IPsec (500), and L2TP (1701)?

They’re different VPN technologies. OpenVPN on 1194 is a userspace SSL/TLS VPN on a single UDP/TCP port. IPsec IKE on UDP 500 (plus 4500 for NAT-Traversal) negotiates kernel-level IPsec tunnels. L2TP on UDP 1701 is a tunneling protocol that’s almost always wrapped in IPsec for encryption. They share the “VPN gateway” role but none of the underlying machinery.

How do I secure or close port 1194?

Enable tls-crypt, issue strong per-user certificates from a managed PKI, require MFA, and drop weak ciphers. Patch both the server and the Windows clients (for the 2024 CVE cluster), push least-privilege routes, and firewall 1194 to expected source ranges where the deployment allows it. If nothing uses the VPN, stop the daemon and confirm the port is closed with a rescan.

TL;DR

• Service: OpenVPN — SSL/TLS remote-access and site-to-site VPN
• Default port: 1194/UDP (also 1194/TCP; frequently 443/TCP to evade filtering)
• Biggest risk: weak or stolen VPN credentials without MFA — a top ransomware initial-access route — plus deferred-auth information disclosure (CVE-2020-15078)
• Also watch: unpatched Windows clients (2024 interactive-service/TAP cluster — CVE-2024-27459/-24974/-27903/-1305, client-side) and pre-auth DoS on old 2.x builds (CVE-2017-7508)
• Mitigation: tls-crypt + strong certs + MFA, patch server and clients, drop weak ciphers, least-privilege routes, monitor authentication