Guides, Nov 10, 2026

# How to test an OpenVPN server and .ovpn file

The only test that proves an OpenVPN server works is a client that connects with a real .ovpn file and gets traffic through the tunnel. A port check is not enough, because OpenVPN often answers nothing to a probe. Run openvpn --verb 4 with the file on a machine outside your network, or paste the file into an online tester, then read where it stopped.

Tahir Mehmood, 10 min read

I checked the log lines and options below against the OpenVPN 2.6 source (the release/2.6 branch, 2.6.23). If you already have an error in a log, you may not need a test at all: `TLS key negotiation failed` has [its own checklist](https://tunnelhq.com/blog/openvpn-tls-key-negotiation-failed/), and `VERIFY ERROR ... certificate has expired` has [its own guide](https://tunnelhq.com/blog/openvpn-certificate-has-expired/).

A useful test answers three questions in order. Is the server reachable? Does it accept this file and this login? Does traffic come back through the tunnel? Most quick checks only answer the first one.

## How do I test an OpenVPN server without a client?

You can't fully. Something has to run an OpenVPN client with a real config, because only a client completes the TLS handshake, sends the login and brings up the tunnel. What you can skip is installing a client on your own laptop: use a second server, a spare VM, or an online tester that runs the client for you.

On the server itself, three commands tell you whether OpenVPN is running and where it listens:

```
systemctl status openvpn-server@server
ss -lunp | grep openvpn      # UDP listeners
ss -ltnp | grep openvpn      # TCP listeners
```

The unit name depends on your distribution and on the config file name; `openvpn-server@server` matches `/etc/openvpn/server/server.conf` on Debian and Ubuntu. Then follow the log while a client tries to connect:

```
journalctl -u openvpn-server@server -f
```

If nothing appears in that log when a client connects, the packets never reached the process. That is a network or firewall problem, not an OpenVPN one. If the server config has a `status` line, the file it names lists the clients connected right now.

None of this proves a user can connect from outside. A server can listen happily on a port the cloud firewall blocks. For that you need a client on another network.

## How do I check an .ovpn file for errors?

Run it with the real client at a higher log level and read the output. OpenVPN has no dry run option, but at `--verb 4` it prints every setting it parsed under a `Current Parameter Settings:` heading before it tries to connect:

```
sudo openvpn --config client.ovpn --verb 4
```

A config OpenVPN can't parse stops at once with a line like this, which names the file, the line number and your OpenVPN version:

```
Options error: Unrecognized option or missing or extra parameter(s) in client.ovpn:14: tls-crypt-v3 (2.6.23)
```

A config that works ends with `Initialization Sequence Completed`. Anything between those two is a network, TLS or login problem, and the next sections cover them.

Before you run it, look at the lines that decide where and how it connects:

```
grep -nE '^(remote|proto|port|dev|auth-user-pass|key-direction|tls-auth|tls-crypt|tls-crypt-v2|<ca>|<cert>|<key>|<tls-auth>|<tls-crypt>|<tls-crypt-v2>)' client.ovpn
```

Things to look for:

-   **A `remote` line with a host and a port.** Without a port, OpenVPN uses 1194. If the server listens elsewhere, that is your bug.
-   **A `proto` that matches the server.** A UDP client never reaches a TCP server, and the other way round.
-   **Inline blocks or files.** A line like `ca ca.crt` or `tls-crypt ta.key` points to a file next to the config. Send the `.ovpn` alone to someone else, or upload it somewhere, and that file is missing. Inline blocks (`<ca>...</ca>`, `<tls-crypt>...</tls-crypt>`) travel with the file.
-   **`key-direction 1` with an inline `<tls-auth>` block.** The client side of a tls-auth key uses direction 1. tls-crypt and tls-crypt-v2 need no direction.
-   **`auth-user-pass`.** If it is there, the server expects a username and password, and the client asks for them.

To read the certificate dates inside the file, the [certificate guide](https://tunnelhq.com/blog/openvpn-certificate-has-expired/) has the `openssl` commands.

## Why does a port check say open when OpenVPN still fails?

Because a port check only proves that something accepts packets on that port. It says nothing about whether OpenVPN will accept your certificate, your tls-crypt key or your login. And for UDP, it often can't even prove that much.

For TCP, `nc` reports success as soon as anything completes the TCP handshake:

```
nc -vz vpn.example.com 443
```

That can be OpenVPN, a web server, or a reverse proxy in front of a dead OpenVPN process. All three say "succeeded".

For UDP, there is no handshake to complete. A scanner sends a packet and waits:

```
sudo nmap -sU -p 1194 vpn.example.com
```

If nothing comes back, nmap reports `open|filtered`, which means "I can't tell". OpenVPN is usually silent here on purpose. With `tls-auth`, `tls-crypt` or `tls-crypt-v2`, the server drops any packet that isn't signed with the shared key before it does anything else. In the source, that is where the server logs `TLS Error: cannot locate HMAC in incoming packet`, `TLS Error: incoming packet authentication failed` or `TLS Error: tls-crypt unwrapping failed`, and sends nothing back. So an open UDP port looks exactly like a closed one from outside.

The reverse also happens: a port check fails while the VPN works, because a firewall answers TCP probes differently from real clients. Either way, the port check is the wrong tool. The WireGuard version of this problem is in [why port monitoring fails](https://tunnelhq.com/blog/why-wireguard-port-monitoring-fails/), and the same reasoning applies to OpenVPN over UDP.

## How do I test OpenVPN over UDP and TCP?

Test each one with its own copy of the config, because a client only uses the `proto` and `remote` it is given. Many servers run two instances, usually UDP on 1194 and TCP on 443, and each needs its own test.

```
cp client.ovpn client-tcp.ovpn
sed -i 's/^proto udp$/proto tcp/; s/^remote vpn.example.com 1194$/remote vpn.example.com 443/' client-tcp.ovpn
sudo openvpn --config client-tcp.ovpn --verb 4
```

The two fail in different ways, which helps when you read a log:

|  | UDP | TCP |
| --- | --- | --- |
| Port check from outside | Can't tell open from filtered | Says open if anything listens |
| Server not reachable | Silence, then `TLS key negotiation failed to occur within 60 seconds` | `Connection refused` or a connect timeout |
| Network that blocks UDP | Same silence as a dead server | Usually works |
| On a lossy path | Recovers better | Slower, because TCP retransmits inside TCP |

If UDP fails and TCP works from the same client, the server is fine and something on the path drops UDP. Hotel, office and some mobile networks do. A phone hotspot is the quickest way to tell.

## How do I test an OpenVPN server online?

Paste the `.ovpn` file into a tester that runs a real client somewhere outside your network. The [TunnelHQ free tester](https://tunnelhq.com/test/) does this. One of its checkers runs the `openvpn` client program itself with your file and the login you type, so inline `tls-auth`, `tls-crypt` and `tls-crypt-v2` blocks are handled by OpenVPN, the same way your own client handles them. When the tunnel is up, it sends traffic through it to well-known public addresses to confirm that the server forwards.

What it needs and what it refuses:

-   **A username and password, always.** The tester asks for them even when the file has `auth-user-pass`. They are used for that one test and not stored.
-   **A self-contained file.** Only the text of the `.ovpn` is sent, so certificates and keys must be inline, not paths to files.
-   **A `remote` line with a port, and `proto udp` or `proto tcp`.** The tester reads the server from the first `remote` line. A `proto` of `udp4` or `tcp-client`, or a `remote` with no port, is refused before the test runs, with a message that says what is missing.
-   **No scripts or plugins.** Lines such as `up`, `down`, `plugin`, `route-up`, `tls-verify` or `management` are refused. Windows-only lines such as `block-outside-dns` are dropped.
-   **Size.** You can upload a file of up to 256 KB, but the config text itself must be under 100 KB. A config with inline certificates is usually under 50 KB.

It ignores the routes and the `redirect-gateway` the server pushes, and routes its own test traffic instead. So a test can pass even if the routes you push to users are wrong. The free tester gives each IP address 5 tests every 24 hours, and a request refused for a bad config counts as one of them.

Use a VPN user made for testing, not your own. If that login ever leaks, you revoke it and nobody else is affected.

## What does each failed test result mean?

A failed test on the tester reads "OpenVPN handshake failed", then a reason, then what the checker saw. The reason is one of two:

-   **Server not connected**: the tunnel never came up. The server didn't answer, the TLS handshake failed, or the login or certificate was refused.
-   **Internet stuck**: the tunnel came up, but traffic through it didn't reach the internet.

The "What the checker saw" box narrows it down. It shows a short label, and usually the OpenVPN log line that triggered it. Read the log line first, because it is more specific than the label. These are the ones you are most likely to see:

| What the checker saw | What it means | What to check |
| --- | --- | --- |
| Handshake timed out | The server never answered | Server down, wrong host or port, UDP blocked, or a tls-auth or tls-crypt key that doesn't match |
| TLS handshake failed, with a `TLS Error:` line | TLS started and broke | The `<ca>`, cipher or TLS version settings, and the [TLS negotiation checklist](https://tunnelhq.com/blog/openvpn-tls-key-negotiation-failed/) |
| Certificate verification failed, with a `VERIFY ERROR:` line | A certificate was rejected | Expiry dates and names; see the [certificate guide](https://tunnelhq.com/blog/openvpn-certificate-has-expired/) |
| Authentication failed, with `AUTH_FAILED` | The login was refused | The username or password, or the server's auth plugin |
| Remote host refused connection | TCP only: nothing listens on that port | The port in `remote` and the server's `port` line |
| DNS resolution failed, with `RESOLVE: Cannot resolve host address` | The host name didn't resolve | The host name in `remote` |
| Client configuration error, with an `Options error:` line | OpenVPN can't parse a line | Run `--verb 4` locally and fix the line it names |
| Tunnel validation failed | `Initialization Sequence Completed`, then no traffic | Forwarding and NAT on the server, its DNS, or an egress firewall |

A certificate that expired often shows up under the TLS label, because OpenVPN logs `TLS Error:` lines right after the `VERIFY ERROR:` line. If the log line mentions a certificate, treat it as a certificate problem.

The last row is the one people miss. The client connects, gets an address, and the user sees a working VPN icon with no internet. On the server, check that forwarding is on and that NAT covers the VPN subnet:

```
sysctl net.ipv4.ip_forward
sudo iptables -t nat -S POSTROUTING
sudo nft list ruleset | grep -i masquerade
```

A tls-crypt key that doesn't match deserves a note, because it looks like a dead server. The server drops the client's packets without a reply, so the client only sees a timeout. If the server log shows `tls-crypt unwrapping failed` from the client's address, the server is up and the key in the file is wrong.

## How do I test OpenVPN from another country?

Run the client from a machine in that country. A server can work from one country and be blocked from another, and a test from the wrong place tells you nothing about the users who complain.

The free tester runs from whichever checker is free, and you can't pick the country. For a one-off, a cheap VM in the country you care about, running `openvpn --verb 4`, is the honest answer.

For a regular check, TunnelHQ monitors on the Pro plan can test from up to 5 countries you pick, and on Business from up to 12. Each country runs its own check, so you see "up from Germany, down from Turkey" instead of one blended answer. The [locations docs](https://tunnelhq.com/docs/concepts/regions/) explain how the results combine.

## How do I keep testing it every few minutes?

Run the same full test on a schedule and alert when it fails. A one-off test tells you the server worked at that moment. The failures that hurt are the ones that start at 3 a.m.: an expired CRL, a full disk, a service that didn't come back after a reboot.

The [TunnelHQ OpenVPN monitor](https://tunnelhq.com/openvpn-monitoring/) runs the same test as the free tester, every 5 minutes on Starter, every 2 minutes on Pro and every minute on Business, and alerts when it fails. It keeps the history, so you can see when a server started failing and from where. Two limits to know before you start: it needs a config with `auth-user-pass`, because certificate-only configs can't be added yet, and it treats a refused login as **Degraded** unless that login passed a check in the last 30 days. The [OpenVPN docs page](https://tunnelhq.com/docs/protocols/openvpn/) has the details. Every plan has a 14-day free trial.

If you'd rather build it yourself, a cron job that runs the client with a timeout and checks for `Initialization Sequence Completed`, then reports to a heartbeat, is a reasonable start. The [VPN server monitoring guide](https://tunnelhq.com/blog/vpn-server-monitoring-guide/) covers what else a server needs watching, such as certificate expiry and disk space, and from where to check it.

Source: https://tunnelhq.com/blog/test-openvpn-server-online/