27850, 442, 651: One Stack, Three First Checks

An installer stops with 27850, a connection refuses with 442, and another profile returns 651. The numbers look like three unrelated faults, and the usual response is to reinstall the client three times. They come from one subsystem: the virtual adapter and the filter stack around it. The error number tells you which layer failed, and that decides the first check. Reinstalling before reading it usually reproduces the same failure.

Match the number to the layer

Each error is raised at a different point, so the first check is different even though the visible symptom is the same refused connection. Three families cover every case: the installer, the adapter, and the port underneath it. The table below puts each number next to the check it implies.

If the error appears before any profile is selected, it belongs to the install family. If it appears when the client tries to bring up the adapter, it belongs to the adapter family. If the adapter is visible and the port never opens, it belongs to the miniport family. Write the number down before changing anything. The three repairs touch different parts of the stack, and a change made for the wrong family makes the next attempt harder to read.

A Full Filter Stack, or a Suite Blocking the Driver

Installing the client registers a small filter component in the adapter chain. Windows has a hard ceiling on how many such components may bind, and the default leaves little room once antivirus, a virtualization bridge and a capture driver are present. The install then fails with 27850 even though the VPN package is fine. The installer cannot tell a crowded stack from a broken one.

Read the current value, raise it, and reboot before retrying. A new filter cannot bind until the stack has been rebuilt:

reg query "HKLM\SYSTEM\CurrentControlSet\Control\Network" /v MaxNumFilters
reg add "HKLM\SYSTEM\CurrentControlSet\Control\Network" /v MaxNumFilters /t REG_DWORD /d 14 /f

The other cause is a security suite that blocks driver installation without a visible prompt. Its self-defence feature can prevent the filter from registering, so the installer reports a generic component failure. Check the suite's own log, and if self-defence is the blocker, disable it only for the install window and restore it immediately afterward. If the count is already raised and no suite is blocking, look for orphaned filter drivers from a previous VPN product. An old filter that no longer has a matching service still occupies a slot and can fail the new install.

The Adapter Is There and Stays Down

Error 442 means the virtual adapter is present and the client cannot bring it up. The first check is Device Manager with hidden devices shown: a disabled adapter, an adapter with a warning badge and a missing adapter look identical in the client but need different repairs. Internet Connection Sharing is a frequent holder. If the service has claimed the adapter, stop the service and retry before touching the registry. A leftover sharing configuration can also re-claim it after a reboot, so note whether the fix survives a restart.

A reinstall can leave a malformed display name that makes the adapter unmanageable. The value should be plain text, not an unresolved installer token:

Get-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CVirtA" -Name DisplayName
Set-ItemProperty "HKLM:\SYSTEM\CurrentControlSet\Services\CVirtA" -Name DisplayName -Value "Cisco Systems VPN Adapter for 64-bit Windows"

Use the display name your client expects, then reboot so the adapter is re-enumerated. Setting the value without a reboot usually leaves the old state in place and the next connect returns 442 again.

The Port Underneath Never Opens

Error 651 is reported when the connection manager cannot open the WAN miniport. The adapter may look healthy in the client while the port underneath it never reaches a started state. List the miniports and their status before reinstalling anything:

Get-PnpDevice -Class Net | Where-Object { $_.FriendlyName -like "*WAN Miniport*" } | Select-Object Status, FriendlyName

A miniport with an error status is the direct clue. Reinstalling it from Device Manager recreates the port, which is why this repair works when a client reinstall does not. Third-party drivers attached to the physical adapter are the other common cause. A VirtualBox bridged networking driver, a leftover TAP driver from OpenVPN or a capture filter can take the port first. Deselecting the component during an install is not enough when the driver is already bound; it has to be removed from the adapter's properties or uninstalled from the driver store.

Disabling IPv6 on the VPN connection has resolved this error on some builds, but treat that as a test rather than a permanent design. If the connection starts only with IPv6 disabled, the underlying miniport or driver is still the fault.

Change one layer and keep the evidence

Save the registry values you change, record the adapter and filter list before and after, and reboot between attempts. A reboot is part of the repair for every family here, because the adapter stack is built at boot and a service restart does not rebuild it.

Reinstall the client only after the old adapter, filters and miniports are gone. Installing a new client over a broken stack is how a repairable 27850 turns into a machine with two half-registered adapters and no clear error. Stop and escalate when the same error survives the layer-specific check twice. At that point the useful next step is a clean network stack review with the vendor's installer log, not another attempt at the same reinstall.