Tunnelblick data-ciphers Unrecognized: Which Engine Ran?

Tunnelblick reports an unrecognized data-ciphers option, mentions OpenVPN 2.4 in the same breath, and the connection never starts. That is a local parsing failure rather than a cipher disagreement, because the engine rejected the profile before any negotiation with the gateway took place. Following the usual advice about server cipher policy cannot help here; the parser has to understand the file first. Find the engine that this one configuration actually launched, and the rest follows.

Read the log line before touching the profile

Open the failing connection in Tunnelblick's details window and read the log from the top. The first lines name the engine version and the profile being handed to it, followed by the option that stopped the parse. Everything after that point is noise, because the process exited.

Record three facts from that log: the engine version, the configuration name and the exact message. Those three are the whole diagnosis. They are also what you will need if the fix turns out to require the installed application to change. Screenshot the lines rather than paraphrasing them, because option names are easy to mistype when repeated from memory.

Confirm which engine that configuration runs

Tunnelblick is an application wrapped around an OpenVPN engine, and different configurations can run different engines. Check the version selected for this configuration in the details window rather than reading the application version, and do not substitute the output of a terminal openvpn binary that the configuration never uses. Tunnelblick's OpenVPN versions guide describes how that selection works and where the choice is stored.

The distinction matters because a machine can have a modern binary on the PATH and a bundled 2.4 engine behind the connection that failed. The profile is evaluated by the second one.

openvpn --version
ls /Applications/Tunnelblick.app/Contents/Resources/openvpn/

Those two commands show what a terminal would run and which engine directories the installed application carries. Neither is proof of what the failing configuration used, since the log already told you that, and paths differ between Tunnelblick releases.

Why the directive name changed

OpenVPN introduced data-ciphers as the negotiation list in 2.5, replacing the earlier ncp-ciphers spelling that became deprecated in that release. A 2.4 engine has no such option, so it stops at the first token it does not know. The single cipher option is not an older alias for the list either; it names one cipher rather than a negotiation set.

That is why text substitution across versions produces profiles that parse and then behave unexpectedly, and why copying a fragment from a forum post is not a version check. The option names moved together with fallback handling and defaults, and a file assembled by renaming one directive is not equivalent to one written for the engine.

Fix the engine or the profile, not the symptom

For a supported deployment, the durable repair is a supported Tunnelblick and engine combination that accepts the operator's profile, arranged through whoever owns the application installation. If an older installation has to stay for a while, ask for a profile written for that engine and for the ciphers the gateway actually accepts.

Deleting data-ciphers and data-ciphers-fallback does clear this particular parse error, which is exactly why it is tempting. It also changes which ciphers are negotiated, silently, in a security configuration you did not intend to edit. Keep the original profile and compare the supported settings deliberately instead.

Retry and read the next stage

After the correction, retry the connection and read the new log from the beginning rather than assuming success. A profile that now parses can still stop at cipher negotiation, at certificate verification, at authentication or at routing, and each of those failures has its own evidence.

If negotiation fails, compare the ciphers the two peers support and the ones each is configured to permit. If authentication fails, the profile and engine are now working well enough to have reached the gateway, which is progress worth recording. Stopping that chain at the first quiet log is how a security setting gets removed for the wrong reason.