OpenVPN will not import profile

You clicked import, OpenVPN threw an options error, and the profile never appeared in the client list. This is a parsing failure, not a connection failure. The client rejected the text before it ever spoke to a server. That means the fix is in the file or in the client version, and never in your credentials. Everything below assumes you already have the file and are trying to import profile data OpenVPN will not accept.

Four causes account for almost all of it. Work through them in the order given, because the first one is free to check and the last one costs you a re-download.

Every OpenVPN client names the failure, and most name the line. Read the whole string before touching anything.

Open the client log rather than the toast notification. OpenVPN Connect keeps an import log separate from the connection log, and the connection log is the one that is usually empty at this point. On the desktop GUI, raise verbosity with verb 4 before retrying so the parser reports more of what it saw.

Note the line number the error gives you. Then count lines in an editor that does not soft-wrap. A wrapped line and a long line look identical on screen, and they are the difference between two of the four causes below.

The line is too long

OpenVPN reads each configuration option into a fixed buffer. Exceed it and the client reports:

Maximum option line length (256) exceeded

That string is exact. It appears verbatim in the OpenVPN support forum thread of the same name and in the Netgate forum thread of the same name. Search on the whole string rather than on the words around it. That is how you separate results about your problem from results about a generic import error.

The usual cause is not a long remote line. It is a certificate or key body that has lost its line breaks. PEM material is normally wrapped at 64 characters. Copy a block through a chat client, a spreadsheet cell or a form field and the wrapping can collapse into one continuous string thousands of characters long. The parser hits the buffer limit on that single line and stops.

Check it in one step. Open the file and turn on the editor's ruler or column indicator, then look for any line past column 256. Fix it by restoring the original wrapping, or by replacing the inline block with a reference to a separate file, or by fetching a clean copy.

One symptom is worth recognising, because it sends people to the wrong section of this page. If the client names an unrecognised option and that option text looks like a fragment of certificate material, check the line lengths first. A parser that ran past the end of a collapsed line reports what it found there, and what it found is not a directive you wrote.

An inline certificate block will not load

The inline mechanism is strict about its delimiters. A block starts with a line containing only <ca> and ends with a line containing only </ca>, and the same applies to <cert>, <key>, <tls-crypt> and the rest. Three things break it.

The closing tag is not on its own line. If the last line of PEM material and </key> share a line, the parser never sees the terminator and consumes the rest of the file into the block. The reported error is then about whatever directive followed, which sends people looking in the wrong place entirely.

There is leading whitespace before a tag. Indenting <cert> by two spaces because an editor auto-formatted the file is enough to stop it matching.

The block is present but empty, or the -----BEGIN and -----END markers were dropped during a copy. The client then reports a load failure naming the inline file rather than a syntax error. Read which block it names, because that is the one to compare against the source.

Fix all three the same way. Confirm each tag sits alone on its own line with no leading spaces. Confirm every PEM body still carries its BEGIN and END markers. Confirm there is a newline after the final block, so the file does not end mid-tag. For what each block contains and why they are inlined at all, see what is inside an .ovpn file.

The line endings are wrong

A profile downloaded on Windows carries CRLF line endings. A profile written on Linux or macOS carries LF. Most OpenVPN builds tolerate both, because the parser strips trailing whitespace from each option before evaluating it.

The case where it does not tolerate both is the inline block. A closing tag line that is </key>\r may fail to match the expected terminator on a client that compares the line strictly. The symptom is then identical to a missing closing tag. Whether your client is that strict is not worth arguing about, because you can settle it in one command.

Test it rather than assume it. On Linux or macOS run file profile.ovpn, which reports CRLF line terminators when they are present. Convert with dos2unix profile.ovpn and retry the import. If the import succeeds after conversion and failed before it, you have your answer. If it fails identically, the endings were never the problem and you have eliminated a cause at no cost.

A directive is deprecated or unrecognised

The client rejects options it does not implement. The string names the option and, on several clients, the line and the version:

Unrecognised option or missing or extra parameter(s) in configuration: (line 6): block-outside-dns (2.4.6)

That example is quoted from Keenetic's support article on the error, which is one of the few pages anywhere that documents it. block-outside-dns is a Windows-only directive, so a router or a non-Windows client that refuses it is behaving correctly. Two fixes exist. Comment the line out with a leading #, or leave it in place and add pull-filter ignore 'block-outside-dns' so a pushed copy is discarded rather than fatal. Keenetic documents both.

Note that ignoring is not the same as being silently accepted. Viscosity reports Warning: The block-outside-dns option has been ignored and states that its own DNS handling makes the directive unnecessary. A warning that names the option is a client telling you it read the line and chose not to act on it. That is a different situation from a parse failure, and it needs no fix.

Removing the line gets the profile imported and leaves you without the protection it provided. That is a DNS problem rather than an import problem, and it is answered in full on the OpenVPN DNS leak fix page, which covers what to use on each platform instead.

Cipher directives are the other common rejection. The OpenVPN 2.6 manual states that --cipher should not be used any longer in TLS mode, and that the option is ignored there. Negotiation runs from --data-ciphers, which in 2.6 defaults to AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305, or to the same list without Chacha20 where that cipher is unavailable. A profile written for an older client can therefore warn about the option, or fail to agree a cipher at all against a newer one.

The correct fix is to add the cipher to data-ciphers on both ends, or to use data-ciphers-fallback. OpenVPN 2.6 documents a third route for old configurations: --compat-mode 2.4.x puts a cipher named by --cipher back into the negotiated list. The incorrect fix, which appears in forum answers regularly, is to delete the cipher line and let the client fall back to whatever it likes. That changes what protects your data channel, and you will not be told when it happens.

Read this table as a decision aid, not as a list of edits to apply speculatively. Every row except the first two is better solved by generating a fresh config than by hand-repairing a file whose provenance you no longer trust.

The import path differs enough that "it will not import" sometimes means "you used the wrong path".

OpenVPN Connect

Use the file import tab rather than dragging the profile onto the window. Connect keeps its own import log, and it reports parse errors there rather than in the connection log. A profile rejected by Connect but accepted by the community GUI usually points at a directive Connect does not implement rather than at a corrupt file.

OpenVPN GUI on Windows

Copy the profile into the client's config directory and reload the tray icon, or use the import item in the tray menu. Confirm the file is named profile.ovpn and not profile.ovpn.txt, because Windows hides known extensions by default and the GUI enumerates only .ovpn.

nmcli and NetworkManager on Linux

The nmcli manual gives the syntax as import [--temporary] type <type> file <file>, so the command is nmcli connection import type openvpn file /path/to/profile.ovpn. The same manual states that VPN configurations are imported by NetworkManager VPN plugins, and that the proper plugin has to be installed for the import to work. Install the OpenVPN plugin first, or the type is simply not recognised.

NetworkManager parses the profile itself and models the directives it understands, so a successful import here does not prove the whole profile survived. Check the resulting connection before assuming it did. Without --temporary the imported profile is written to disk, which is what you want for a connection you intend to keep.

Android and iOS

Both platforms copy the profile into app storage at import time. Transfer the file with a file manager, USB or the Files app rather than a chat client. Chat clients re-encode attachments, and that is one route to the unwrapped-PEM problem above. If a file imports on desktop and fails on the phone, suspect the transfer before you suspect the file.

Three failures look like a bad profile and are not.

The file is saved as profile.ovpn.txt. Turn on file extensions and rename it. The client will not list a file it cannot see.

The file is truncated. A download interrupted at 80 percent produces a profile that ends mid-certificate, and the resulting error points at the last complete line rather than at the missing remainder. Compare the file size against the source, or simply download it again.

The client cannot read the file. On Linux a profile in another user's home directory, or one owned by root with restrictive permissions, fails to open for a client running unprivileged. Check with ls -l before editing anything.

Stop repairing a file once you have edited it more than twice. A hand-patched profile with restored line wrapping and re-indented tags is a file whose inline material you can no longer verify.

Download a fresh profile from the provider, import it without editing it, and only then reapply any change you genuinely need. If the fresh copy imports and yours did not, the fault was in the copy rather than in the client. That result is worth more than an afternoon in the log. See generating a fresh config for the procedure, and importing a config file for the client-side half.

For the import procedure itself, see importing a config file. For what happens after the profile loads, see using your OpenVPN profile. For failures that occur after a successful import, see connection troubleshooting.