What is an .ovpn file and how to open it

An .ovpn file is a plain text OpenVPN client profile. It holds the directives that tell the client where to connect and how, plus the certificates and keys inlined as text blocks between tags. Anyone asking what is an ovpn file usually wants two answers: what the file contains, and which program opens it.

The file is not encrypted, not compiled and not proprietary. Open it in any text editor and you can read every line. That matters more than it sounds, because a profile you can read is a profile you can fix.

A profile is a list of options, one per line, in the same syntax the openvpn binary accepts on the command line. The client reads the file from top to bottom. Blank lines are ignored, and a line starting with # or ; is a comment.

Three kinds of content appear. Connection directives describe the endpoint and the transport. Inline blocks carry the cryptographic material. Routing and DNS directives decide what happens to your traffic once tun0 comes up.

The extension is a convention rather than a format. OpenVPN reads the same syntax from a file named .conf, and many Linux packages use that name for the server side. Windows and mobile clients enumerate .ovpn specifically, which is the practical reason the extension exists. Nothing changes inside the file when you rename it.

The connection directives

These are the lines that decide where the client dials and how it behaves while dialling.

client marks the profile as a client configuration. It is shorthand for pull and tls-client, so removing it breaks the profile outright. dev tun selects a routed IP tunnel rather than a bridged Ethernet one. proto udp selects the transport, and it must match what the server listens on.

remote vpn.example.com 1194 names the host and port. A profile may carry several remote lines, and the client tries them in order unless remote-random is set. resolv-retry infinite keeps the client retrying name resolution instead of exiting when DNS is briefly unavailable. nobind tells the client not to bind to a fixed local port, which is what you want on a laptop.

The inline blocks

OpenVPN supports embedding a file directly in the configuration. The mechanism is documented in the OpenVPN manual as inline files: each block starts with a line containing <option> and ends with a line containing </option>.

The options that accept inline content are --ca, --cert, --dh, --extra-certs, --key, --pkcs12, --crl-verify, --http-proxy-user-pass, --tls-auth, --auth-gen-token-secret, --peer-fingerprint, --tls-crypt, --tls-crypt-v2, --verify-hash and --auth-user-pass. Anything not on that list must still reference a path on disk. Inline --pkcs12 content has to be base64 encoded first.

Inlining is why a modern profile is a single file. A provider that hands you client.ovpn plus ca.crt, client.crt and client.key is handing you four things that must stay together. A provider that inlines them hands you one file that works anywhere you can copy it. That portability is the whole reason the format is used the way it is.

The directives that control routing and DNS

redirect-gateway def1 is the line that sends everything through the tunnel. It installs two half-width routes, 0.0.0.0/1 and 128.0.0.0/1, which override the existing default gateway without deleting it. Remove it and only the subnets the server explicitly pushes will route through the VPN.

dhcp-option DNS 10.8.0.1 supplies a resolver. On Windows the client applies it to the tunnel adapter directly. On Linux and macOS the directive is only a piece of data until an up script does something with it, which is the root of most leak reports. block-outside-dns blocks queries to resolvers outside the tunnel using the Windows Filtering Platform, and it is a Windows-only directive. Every other platform ignores it or refuses it.

Here is a profile with the certificate bodies removed. The shape is what matters.

client
dev tun
proto udp
remote vpn.example.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
auth-user-pass
auth-nocache
verb 3

<ca>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</ca>

<cert>
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
</cert>

<key>
-----BEGIN PRIVATE KEY-----
...
-----END PRIVATE KEY-----
</key>

<tls-crypt>
-----BEGIN OpenVPN Static key V1-----
...
-----END OpenVPN Static key V1-----
</tls-crypt>

Two things about that shape are worth noticing before the table. The directives come first and the inline blocks come last, which is convention rather than a rule, but it makes the file readable and every generator follows it. And the profile is short. A client configuration is usually fifteen to twenty-five directives, because the server pushes the rest at connection time and the client accepts them through the implied pull.

Read the file against the table below. The third column is the one worth reading twice.

Two rows deserve to be said plainly rather than left in a cell. Deleting remote-cert-tls server removes the check that stops a peer holding any certificate signed by the same CA from posing as your server. Weakening data-ciphers to satisfy an old client downgrades the data channel for every session that profile makes. Neither change produces an error, which is exactly why both are worth avoiding.

What a PulseVPN profile contains

The example above is a composite. A real profile is shorter than the table suggests, and it is worth seeing one service described exactly rather than generically.

A PulseVPN profile opens with client and dev tun, then names its endpoint. Four things about the rest are worth knowing before you open one.

• Two remote lines, both on port 80, with proto tcp in one file of the pair and proto udp in the other.
• auth-user-pass with no filename argument, so the client prompts for a username and a password.
• tun-mtu 1500, cipher AES-256-CBC, comp-lzo, ns-cert-type server, key-direction 1 and route-method exe.
• An inline <ca> block, with no <cert> and no <key> block, because there is no client certificate to carry.

Four directives discussed on this page are simply absent. There is no redirect-gateway, no block-outside-dns, no data-ciphers and no mssfix. A Windows user who wants the DNS block adds it, and the absence of data-ciphers is why the older cipher line is the one you see. Remember that routing options missing from a profile can still arrive from the server through the implied pull. Read the client log rather than the file to see what was installed.

Each server is delivered as a ZIP holding both profiles, named <server>_udp.ovpn and <server>_tcp.ovpn. Reading the two files side by side is the shortest way to see how little a transport change actually alters.

The file is text, so any editor opens it for reading. Importing it into a client is a different action, and the client differs per platform. Nothing opens an .ovpn file by itself, because the extension has no default handler until you install a client. That is why double-clicking a fresh download usually produces a file-association dialog rather than a VPN connection.

Install the client first. Import second. Reversing the order is the single most common reason a profile appears to do nothing.

Windows

Install the OpenVPN GUI from the OpenVPN community downloads, or install OpenVPN Connect. With the GUI, copy the profile into the client config directory and right-click the tray icon to connect. With OpenVPN Connect, use the file import dialog and point it at the .ovpn.

macOS

Install Tunnelblick or OpenVPN Connect. Tunnelblick imports on double-click and asks whether to install the configuration for one user or all users. OpenVPN Connect uses the same import dialog it uses on Windows.

Linux

Run the profile directly with sudo openvpn --config /path/to/profile.ovpn, or import it into NetworkManager. The NetworkManager import command is nmcli connection import type openvpn file /path/to/profile.ovpn, and it requires the network-manager-openvpn plugin. NetworkManager derives the connection name from the filename.

Android

Install OpenVPN for Android or OpenVPN Connect from the Play Store. Both accept a file from local storage or a share intent. Transfer the profile by USB, by SD card or through a file manager rather than through a chat app, for the reason given in the FAQ below.

iOS

Install OpenVPN Connect from the App Store. Getting the file onto the device is the awkward half. Use the Files app, AirDrop or iTunes file sharing, then open the profile and choose OpenVPN Connect as the handler.

Router or NAS

OpenWrt, pfSense, Synology and QNAP each accept an OpenVPN client profile through their own web interface, and each has its own upload path. Several router firmwares reject directives they do not implement, block-outside-dns most commonly. Read when OpenVPN will not import your profile before editing anything out by hand.

Paths move between client versions and packages. Confirm yours before assuming.

The two Windows rows come from OpenVPN GUI's own documentation, which reads a system-wide configuration directory and a per-user one, and searches the immediate subdirectories of both. That documentation also describes a config_dir registry value, so an installation on your machine can be pointed somewhere else entirely. If none of that appeals, use the client's Import file function and let it choose.

The pattern behind the table is the useful part. Desktop clients that run as a service read from a directory. Mobile clients copy the profile into their own storage at import time, so deleting the original file afterwards changes nothing.

That distinction decides how you update a profile. On a desktop client reading from a directory, replacing the file on disk is enough. On a mobile client, and on NetworkManager, the imported copy is what runs, so a new profile has to be imported again before anything changes. Delete the old entry first, or you will end up with two connections whose names differ by a numeric suffix.

Treat the file as two halves. The directives are yours to tune. The inline blocks are not.

• Change log verbosity, retry behaviour and credential handling freely, since verb, resolv-retry and auth-nocache affect only your client.
• Change the endpoint and the transport only to values the provider publishes, because a remote line pointing nowhere fails silently until timeout.
• Change routing and DNS deliberately, since redirect-gateway def1 and dhcp-option DNS decide whether traffic and lookups leave through tun0.
• Change nothing inside <ca>, <cert>, <key> or <tls-crypt>, because a single altered character invalidates the whole block.

For what the tunable directives actually do, the OpenVPN directives worth knowing reference covers the flags in this article and several more. For the resolver side specifically, see DNS settings in the profile.

An import failure is a parsing problem, not a connection problem. The client is rejecting the text before it ever reaches the server. Four causes account for almost all of it: option line length, malformed inline block delimiters, line endings and deprecated directives. Each is covered in the dedicated page on when OpenVPN will not import your profile.

For the product-side procedure, see using your OpenVPN profile. To load the file into a client, see importing a config file. To replace a profile you have edited past the point of trust, see generating a new config.