OpenVPN says ncp-disable is unknown: what replaced it?

The client refuses to start with an options error naming ncp-disable, and the profile worked on the previous machine. That message does not mean the option was misspelled or that encryption is broken. It means the binary in front of you does not know the directive at all, and there are two very different reasons for that. Which one applies decides whether you edit the profile or change the client.

The error can come from a newer binary

An unrecognized-option error is about the parser, not the tunnel. OpenVPN 2.4 added negotiable cipher parameters, 2.5 deprecated the switch that disabled them, and 2.6 removed it entirely. A profile written for 2.3 or 2.4 therefore fails on a current client even though nothing in the file changed. The version complaining is newer, not older.

Find out which executable produced the message before editing anything. A desktop client bundles its own engine, while a separately installed command-line binary has its own version. The two can disagree on the same machine.

openvpn --version settles it for the binary you are testing. A GUI client may not expose that command, in which case read its about screen or the bundled library version.

What the option actually controlled

The directive disabled negotiation of cryptographic parameters, so both ends fell back to older selection behaviour driven by the cipher setting. It never disabled encryption, and it never turned the tunnel into plaintext. Reading it as a security switch is the first wrong turn, and it leads to changes that make the connection worse rather than better.

Once negotiation exists, the equivalent question is which ciphers each side is willing to use. That is a policy question, and policy lives in data-ciphers on 2.5 and later.

The older name ncp-ciphers belongs to 2.4. Mixing the two names across peers is a common source of one-way negotiation failures. A profile carrying both is a profile edited by two people at different times.

Replace the policy, not the spelling

Set data-ciphers on both peers with an intended shared choice, and keep the list short enough that a reviewer can reason about it. Changing one arbitrary line proves nothing; the result depends on the intersection of both lists and on what the TLS stack supports. Confirm the peers agree by reading the negotiated result rather than the configuration. Then write the pair of lists into the deployment record so the next change starts from a known state.

Update the profile through whoever owns it. Adding an ignore option to hide an obsolete directive leaves the policy question unanswered.

If an older peer genuinely needs compatibility handling, scope it to that deployment. Restoring deprecated behaviour globally is not a prerequisite for connecting modern peers. The exception should name the peer it exists for.

Two lines that look like a cipher list but are not

Stacking two cipher lines does not restore negotiation either, and the result is a profile that looks like a list while behaving like a single value. One line naming AES-256-CBC and the next naming CBC is a common attempt. CBC on its own names a mode rather than an algorithm, so a parser may take it in one slot and reject it in the next. Repeated cipher directives set the same option twice instead of accumulating candidates.

Check accepted names with openvpn --show-ciphers on the target binary instead of copying a list from a guide written for another branch. The list changes between releases. A name valid in one branch is not necessarily valid in the other.

If the goal was a performance comparison, record the algorithms and the workload. Switching to CBC is not a measurement of encryption being absent.

Check what the connection actually negotiated

Bring up a fresh connection and read the data-channel line in the log, which names the cipher in use. The control-channel suite is decided separately, so a permitted list in the file shows only what was on offer. When the two peers selected something you did not expect, the lists are where to look rather than the tunnel interface. Confirm the result on a second connection after any change, because one restart can reuse a cached session.

Keep the negotiated result in the deployment record beside the profile version. That is the fact that answers the next question about which cipher is really protecting traffic.