Viscosity hangs indefinitely during connection (Windows 11 Update issue)

Viscosity Support (Windows)
1

Hi everyone,

I’m experiencing a persistent issue where Viscosity hangs indefinitely during the connection process on Windows 11. This started happening suddenly, most likely following a recent Windows update.

When I initiate the connection, Viscosity gets stuck right after outputting the OpenVPN and library versions. It stays in the “Connecting” state forever until I manually click disconnect.

Here is the log:

Jul 14 9:04:52 AM: State changed to Connecting
Jul 14 9:04:52 AM: Viscosity Windows 1.13 (1877)
Jul 14 9:04:52 AM: Running on Microsoft Windows 11 Home 64 bit
Jul 14 9:04:52 AM: Running on .NET Framework Version 4.8.09221.533509
Jul 14 9:04:52 AM: Checking reachability status of connection...
Jul 14 9:04:52 AM: Connection is reachable. Starting connection attempt.
Jul 14 9:04:52 AM: Interface Type: ViscTunTap
Jul 14 9:04:52 AM: No associated network adapter was found, creating one. This process may take up to a minute or two.
Jul 14 9:04:53 AM: DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
Jul 14 9:04:53 AM: OpenVPN 2.6.21 Windows [SSL (OpenSSL)] [LZO] [LZ4] [AEAD]
Jul 14 9:04:53 AM: library versions: OpenSSL 3.5.7 9 Jun 2026, LZO 2.10
------------ after disconnect command
Jul 14 9:07:36 AM: State changed to Disconnecting (Manual)
Jul 14 9:07:36 AM: Signal received from management interface, exiting

To save time, here are the troubleshooting steps I have already taken (none of which resolved the issue):

  1. Complete Reinstall: Uninstalled and reinstalled Viscosity, including completely removing the TAP/TUN virtual adapters via Device Manager.

  2. Driver Variants: I tried forcing windows-driver wintun via advanced commands, and also tried using the Legacy TAP adapter.

  3. NDIS Filters & Conflicts: Disabled third-party NDIS filters (Kaspersky VPN, ZeroTier, Killer Network Services) to ensure no other service is hooking into the newly created interface.

  4. Routing & Network Stack: Ran netsh winsock reset, netcfg -d, and checked the routing table (route print). There are no ghost routes, but it seems Windows is failing to bind the new virtual adapter to the TCP/IP stack properly, causing OpenVPN to deadlock waiting for the interface.

  5. Other Clients: Other OpenVPN-based clients (like the official OpenVPN GUI and Sophos Connect) also fail or timeout in similar ways, whereas non-OpenVPN tools (like WireGuard/ZeroTier) work perfectly fine.

Current Workaround: To maintain my workflow and establish a connection, I am currently forced to use the Pritunl client or run OpenVPN directly through WSL. Both of these methods successfully bypass the issue.

It feels like a recent Windows 11 update fundamentally broke the way OpenVPN interacts with the virtual network adapter creation/binding process on the host OS.

Has anyone encountered this specific deadlock recently, or is there a known workaround to force Windows 11 to allow the OpenVPN core to bind to the adapter successfully via Viscosity?

Any help would be greatly appreciated. Thanks!

2

Hi esahins,

This looks likely to be caused by third-party security software on your computer. OpenVPN looks to be waiting for a management connection from Viscosity that never comes, which likely means something on your machine is blocking the connection.

Check for any security software you may have installed (such as firewall software, endpoint security software, antivirus software, filtering software, etc.) and try white/allow-listing Viscosity’s executables, or try temporarily uninstalling the software and see if the issue persists.

If you’re still stuck you may be able to get more information from the connection log with the log verb level raised (see this article for how to do this), or from the Windows Event Viewer.

Cheers,
James

3

Hi James,

Thanks for pointing me in that direction. I dug a bit deeper using Sysinternals TCPView to monitor the management connection, and I found something interesting.

The connection isn’t actually being blocked at the network level. When I initiate the connection in Viscosity, TCPView shows that the TCP socket on localhost (e.g., port 49961) successfully reaches the Established state between the OpenVPN core and Viscosity. The TCP handshake completes perfectly.

However, immediately after the connection is established, the process hangs indefinitely. The logs freeze right after printing the OpenSSL/LZO library versions, and the management interface hold-release command never seems to go through.

This suggests that while the port isn’t blocked by a standard firewall, a deep packet inspection (DPI) module from my endpoint security (Kaspersky) or network optimizer (Killer Network Services on my Alienware) is likely hooking into the established localhost socket and silently dropping/quarantining the actual management payload data.

I will try completely uninstalling the security software rather than just disabling it to see if the kernel-level hooks are the culprit. Has the Viscosity team seen this specific behavior (Established TCP state but frozen payload) with recent Windows 11 updates or specific DPI engines?

Thanks again for the help!

4

We have seen security software block the management connection before, but I can’t say anyone has looked into it in that level of detail.

It’s of course possible something else is going on as well, so if removing the security software doesn’t do the trick, please post (or email to us) a copy of your configuration data and logs, and we’ll see if anything stands out.

Cheers,
James