Viscosity Export vs a Plain OpenVPN Profile on Linux

Renaming a Viscosity .visz file to .ovpn does not change what sits inside, because the extension never described a protocol. The comparison that matters is between a bundle with dependencies and a plain client profile with none. Decide which container you actually received before asking a Linux importer to read it.

What each container holds

Viscosity's export documentation describes a .visc connection bundle and a .visz archive form, which is a compressed tar archive. A bundle carries the configuration together with the certificate, key and script files it depends on. A plain OpenVPN profile is one file, and anything it references has to exist separately or be embedded inline.

That difference is the whole comparison. The bundle's relationships are part of the artifact; the plain profile's relationships are an assumption. Moving a bundle to Linux without preserving those relationships produces a file that opens and then fails at the first missing reference. A profile that inlines its certificates avoids that failure by carrying everything in one place, which is convenient until someone needs to rotate one of them.

The outer extension tells you which container you have, not which client can use it.

Where the configuration actually starts

Inside the bundle, the vendor documents a config.conf alongside the dependent files, with references resolved locally. That file is the starting point, not the archive's name and not whichever certificate happens to sit at the top of the directory listing.

On Linux the bundle can appear as a directory rather than a single object, because the archive expands into files that expect to sit together. Keep relative paths coherent in the workspace you extract to, and do not translate a Windows absolute path into a Linux one by hand. A missing dependent file and a wrong path produce the same complaint from the client.

Deleting a trust or identity option to silence that complaint is not a fix.

What the bundle does not carry across

Viscosity's own preferences are not all OpenVPN options. Scripts, route behaviour and application settings may need to be represented by the Linux client's supported integration rather than copied as text another program can execute.

Treat an included script as data until you have read it and decided it is authorized. Running it because the export contained it inverts the review you were supposed to perform. The same caution applies to embedded credentials: a bundle can carry private key material, so a working copy belongs in a protected location rather than a downloads folder.

The original stays protected until the migration is accepted.

What the Linux side must decide

Decide who will own the connection: Community OpenVPN on its own, the NetworkManager plugin, or some other supported client. Each accepts a different option set, and each owns routes, resolvers and secrets differently. A file that opens successfully in one importer can be rejected by another, and success at import does not prove compatibility with the intended connection. Ask the operator whether a Linux-compatible profile already exists, because starting from the supported artifact is shorter than translating one.

Keep server trust, client identity and private-key protection as three separate questions.

The review before you connect

Check the endpoint and transport, the authentication method, every file reference, and the intended route and DNS policy. Then verify the connection and the required application independently, because a tunnel that comes up says nothing about whether the application can reach what it needs.

openvpn --config ./config.conf --verb 4

Compare the negotiated result with what the operator says the profile should do, and note any option the Linux client ignored.

When the migration is accepted, retire the transfer copies through the normal credential-handling process. A bundle left in a shared folder is a credential left in a shared folder.