What an .ovpn file actually contains, and what it cannot do

Most people assume an .ovpn file configures a VPN. It does not: it configures one client, and everything it asks for has to already exist on the other side. Changing a line in the file can change what your machine tries, never what the server offers. That distinction explains most of the confusion around profiles that fail to import or connect.

Read the file as a request list addressed to your client, and most of its lines become obvious.

The file describes your client, not the server

A profile bundles a remote endpoint, a transport, an interface type, identity material, and any client-side behaviour the operator wants. Each line is executed by the client at startup. None of them reach the server as a configuration change, and none of them can create a listener that is not already running. A profile that names TCP 443 against a server listening only on UDP 1194 fails at the first packet.

This is also why the same file behaves differently on two clients: the file asks, and the client decides how much of the request it can honour.

Transport lines must match a listener that already exists

The proto and remote lines have to agree with what the server actually binds. UDP is the usual choice because a lost datagram does not stall the tunnel, while TCP can survive restrictive networks at the cost of head-of-line blocking inside the tunnel. Switching a profile from UDP to TCP does not make the server accept TCP; it only makes the client send to a port nobody is reading.

Port 443 is popular because it passes networks that allow little else, and it remains an OpenVPN session rather than an HTTPS request. If the operator publishes several remote lines, the client tries them in order, which is a failover list rather than a load-balancing decision. Keep the combinations the operator shipped instead of mixing a host from one entry with a port from another.

Embedded keys change how you handle the file

Certificates and keys can sit inline between <ca>, <cert> and <key> tags, or be referenced as separate files. Inline material makes the profile self-contained and also makes it a secret, because the client private key travels inside it. A CA certificate is public trust material and is safe to share; a private key is not, even when it looks like an unreadable block of text.

The passphrase protecting a key is a separate secret from the account password, and mixing them up produces an authentication failure that looks like a wrong credential.

Routes and DNS may not come from the file at all

Routing can be pushed by the server, set by the profile with redirect-gateway, or left to the client's own defaults. The file you downloaded therefore does not fully determine where traffic goes after the tunnel comes up. When internal names resolve and public sites do not, the split-tunnel policy is doing what it was designed to do, not failing.

DNS follows the same pattern: a pushed dhcp-option DNS may be applied by the client, ignored, or overridden by a local resolver manager. Check the resolver state after connecting rather than reading the profile again.

Unsupported options are a client-version question

Import warnings usually mean the client does not implement a directive, not that the file is corrupt. Desktop clients can run scripts and plugins under documented controls, while mobile clients accept a narrower set and may silently drop lines they do not understand. A cipher or TLS setting that an older client refuses is a version problem to solve with the operator. Enabling unfamiliar privileges to force an import trades a warning for a wider attack surface.

Keep the original file for comparison, note the exact unsupported directive in your request, and ask for a profile built for the client you actually run.

After any replacement, confirm which profile entry the app is using, because importing a new file does not always overwrite the old one.