Problems with Viscosity and Crowdstrike when running local VPN

jesteban · 3 April 2025 16:28

Hi there, I am experiencing a very strange issue that I’m also trying to solve with CrowdStrike’s support and we have tried everything with them, but so far they don’t see any error on their part, so I’m turning here in case you can spot something. The problem is as follows, we have a dockerized environment to which we connect through a local VPN using Viscosity. This problem started happening after installing CrowdStrike and stopped occurring when uninstalling it, thus we thought the issue might be there. However, the problem only occurs when trying to connect against the local docker environment, it does not happen when connecting to other of our internal VPNs, and to add even more, the local VPN works when only using VPN, ruling out a VPN configuration problem.

Here are the logs of the faulty connection:

Mar 27 6:00:08 PM: State changed to Connecting
Mar 27 6:00:08 PM: Viscosity Windows 1.11.4 (1835)
Mar 27 6:00:08 PM: Running on Microsoft Windows 11 Pro 64 bit
Mar 27 6:00:08 PM: Running on .NET Framework Version 4.8.09032.533320
Mar 27 6:00:09 PM: Checking reachability status of connection...
Mar 27 6:00:09 PM: Connection is reachable. Starting connection attempt.
Mar 27 6:00:09 PM: Interface Type: ViscTunTap
Mar 27 6:00:09 PM: Bringing up interface...
Mar 27 6:00:09 PM: Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Mar 27 6:00:09 PM: Current Parameter Settings:
Mar 27 6:00:09 PM:   config = 'stdin'
Mar 27 6:00:09 PM:   mode = 0
Mar 27 6:00:09 PM:   show_ciphers = DISABLED
Mar 27 6:00:09 PM:   show_digests = DISABLED
Mar 27 6:00:09 PM:   show_engines = DISABLED
Mar 27 6:00:09 PM:   genkey = DISABLED
Mar 27 6:00:09 PM:   genkey_filename = '[UNDEF]'
Mar 27 6:00:09 PM:   key_pass_file = '[UNDEF]'
Mar 27 6:00:09 PM:   show_tls_ciphers = DISABLED
Mar 27 6:00:09 PM:   connect_retry_max = 0
Mar 27 6:00:09 PM: Connection profiles [0]:
Mar 27 6:00:09 PM:   proto = udp
Mar 27 6:00:09 PM:   local = '[UNDEF]'
Mar 27 6:00:09 PM:   local_port = '[UNDEF]'
Mar 27 6:00:09 PM:   remote = '127.0.0.1'
Mar 27 6:00:09 PM:   remote_port = '11943'
Mar 27 6:00:09 PM:   remote_float = DISABLED
Mar 27 6:00:09 PM:   bind_defined = DISABLED
Mar 27 6:00:09 PM:   bind_local = DISABLED
Mar 27 6:00:09 PM:   bind_ipv6_only = DISABLED
Mar 27 6:00:09 PM:   connect_retry_seconds = 1
Mar 27 6:00:09 PM:   connect_timeout = 120
Mar 27 6:00:09 PM:   socks_proxy_server = '[UNDEF]'
Mar 27 6:00:09 PM:   socks_proxy_port = '[UNDEF]'
Mar 27 6:00:09 PM:   tun_mtu = 1500
Mar 27 6:00:09 PM:   tun_mtu_defined = ENABLED
Mar 27 6:00:09 PM:   link_mtu = 1500
Mar 27 6:00:09 PM:   link_mtu_defined = DISABLED
Mar 27 6:00:09 PM:   tun_mtu_extra = 0
Mar 27 6:00:09 PM:   tun_mtu_extra_defined = DISABLED
Mar 27 6:00:09 PM:   tls_mtu = 1250
Mar 27 6:00:09 PM:   mtu_discover_type = -1
Mar 27 6:00:09 PM: NOTE: --mute triggered...
Mar 27 6:00:09 PM: 221 variation(s) on previous 100 message(s) suppressed by --mute
Mar 27 6:00:09 PM: OpenVPN 2.6.12 Windows [SSL (OpenSSL)] [LZO] [LZ4] [AEAD]
Mar 27 6:00:09 PM: library versions: OpenSSL 3.0.15 3 Sep 2024, LZO 2.10
Mar 27 6:00:09 PM: Valid endpoint found: 127.0.0.1:11943:udp
Mar 27 6:00:10 PM: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 27 6:00:10 PM: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 27 6:00:10 PM: Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
Mar 27 6:00:10 PM: Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
Mar 27 6:00:10 PM: TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:11943
Mar 27 6:00:10 PM: Socket Buffers: R=[65536->65536] S=[65536->65536]
Mar 27 6:00:10 PM: UDPv4 link local: (not bound)
Mar 27 6:00:10 PM: UDPv4 link remote: [AF_INET]127.0.0.1:11943
Mar 27 6:00:10 PM: State changed to Authenticating
Mar 27 6:00:10 PM: TLS: Initial packet from [AF_INET]127.0.0.1:11943, sid=62965e39 098c2c7d
Mar 27 6:00:10 PM: VERIFY OK: depth=1, CN=localhost
Mar 27 6:00:10 PM: VERIFY KU OK
Mar 27 6:00:10 PM: Validating certificate extended key usage
Mar 27 6:00:10 PM: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mar 27 6:00:10 PM: VERIFY EKU OK
Mar 27 6:00:10 PM: VERIFY OK: depth=0, CN=localhost
Mar 27 6:00:10 PM: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
Mar 27 6:00:10 PM: [localhost] Peer Connection Initiated with [AF_INET]127.0.0.1:11943
Mar 27 6:00:10 PM: TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
Mar 27 6:00:10 PM: TLS: tls_multi_process: initial untrusted session promoted to trusted
Mar 27 6:00:10 PM: State changed to Connecting
Mar 27 6:00:10 PM: SENT CONTROL [localhost]: 'PUSH_REQUEST' (status=1)
Mar 27 6:00:10 PM: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,route 172.18.0.0 255.255.0.0,dhcp-option DOMAIN herma.test,dhcp-option DOMAIN shorten.test,dhcp-option DOMAIN email.test,dhcp-option DOMAIN client.test,dhcp-option DOMAIN farmherma.test,dhcp-option DOMAIN jungleherma.test,route 192.168.255.1,topology net30,ping 2,ping-restart 15,dhcp-option DNS 172.18.0.5,ifconfig 192.168.255.6 192.168.255.5,peer-id 1,cipher AES-256-GCM'
Mar 27 6:00:10 PM: OPTIONS IMPORT: --ifconfig/up options modified
Mar 27 6:00:10 PM: OPTIONS IMPORT: route options modified
Mar 27 6:00:10 PM: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mar 27 6:00:10 PM: interactive service msg_channel=0
Mar 27 6:00:10 PM: ROUTE_GATEWAY 192.168.11.1/255.255.255.0 I=48 HWADDR=b4:45:06:3e:a3:9a
Mar 27 6:00:10 PM: Awaiting adapter to come up...
Mar 27 6:00:10 PM: Virtual Adapter Version: 0.8.2.1019
Mar 27 6:00:20 PM: TAP-WIN32 device [HERMA] opened: \\?\root#net#0004#{adda4c48-c32e-4ef6-9602-b3252f082583}, index: 31
Mar 27 6:00:20 PM: TAP-Windows MTU=1500
Mar 27 6:00:22 PM: Waiting for DNS Setup to complete...
Mar 27 6:00:24 PM: Successful ARP Flush on interface [31] {69EA3B42-5A56-47C1-9581-262C3470E8B8}
Mar 27 6:00:24 PM: do_ifconfig, ipv4=1, ipv6=0
Mar 27 6:00:24 PM: Data Channel MTU parms [ mss_fix:1399 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
Mar 27 6:00:24 PM: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mar 27 6:00:24 PM: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Mar 27 6:00:24 PM: Data Channel: cipher 'AES-256-GCM', peer-id: 1, compression: 'stub'
Mar 27 6:00:24 PM: Timers: ping 2, ping-restart 15
Mar 27 6:00:24 PM: [localhost] Inactivity timeout (--ping-restart), restarting
Mar 27 6:00:24 PM: TCP/UDP: Closing socket
Mar 27 6:00:24 PM: Closing TUN/TAP interface
Mar 27 6:00:24 PM: TAP: DHCP address released
Mar 27 6:00:24 PM: SIGUSR1[soft,ping-restart] received, process restarting
Mar 27 6:00:24 PM: Valid endpoint found: 127.0.0.1:11943:udp
Mar 27 6:00:25 PM: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 27 6:00:25 PM: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Mar 27 6:00:25 PM: Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
Mar 27 6:00:25 PM: Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
Mar 27 6:00:25 PM: TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:11943
Mar 27 6:00:25 PM: Socket Buffers: R=[65536->65536] S=[65536->65536]
Mar 27 6:00:25 PM: UDPv4 link local: (not bound)
Mar 27 6:00:25 PM: UDPv4 link remote: [AF_INET]127.0.0.1:11943
Mar 27 6:00:25 PM: State changed to Authenticating
Mar 27 6:00:25 PM: TLS: Initial packet from [AF_INET]127.0.0.1:11943, sid=94d18b70 87a6b036
Mar 27 6:00:25 PM: VERIFY OK: depth=1, CN=localhost
Mar 27 6:00:25 PM: VERIFY KU OK
Mar 27 6:00:25 PM: Validating certificate extended key usage
Mar 27 6:00:25 PM: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Mar 27 6:00:25 PM: VERIFY EKU OK
Mar 27 6:00:25 PM: VERIFY OK: depth=0, CN=localhost
Mar 27 6:00:25 PM: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
Mar 27 6:00:25 PM: [localhost] Peer Connection Initiated with [AF_INET]127.0.0.1:11943
Mar 27 6:00:25 PM: TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
Mar 27 6:00:25 PM: TLS: tls_multi_process: initial untrusted session promoted to trusted
Mar 27 6:00:25 PM: State changed to Connecting
Mar 27 6:00:25 PM: SENT CONTROL [localhost]: 'PUSH_REQUEST' (status=1)
Mar 27 6:00:25 PM: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,route 172.18.0.0 255.255.0.0,dhcp-option DOMAIN herma.test,dhcp-option DOMAIN shorten.test,dhcp-option DOMAIN email.test,dhcp-option DOMAIN client.test,dhcp-option DOMAIN farmherma.test,dhcp-option DOMAIN jungleherma.test,route 192.168.255.1,topology net30,ping 2,ping-restart 15,dhcp-option DNS 172.18.0.5,ifconfig 192.168.255.6 192.168.255.5,peer-id 0,cipher AES-256-GCM'
Mar 27 6:00:25 PM: OPTIONS IMPORT: --ifconfig/up options modified
Mar 27 6:00:25 PM: OPTIONS IMPORT: route options modified
Mar 27 6:00:25 PM: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Mar 27 6:00:25 PM: interactive service msg_channel=0
Mar 27 6:00:25 PM: ROUTE_GATEWAY 192.168.11.1/255.255.255.0 I=48 HWADDR=b4:45:06:3e:a3:9a

And these are the logs of a good connection:

Apr 01 9:15:13 AM: State changed to Connecting
Apr 01 9:15:13 AM: Viscosity Windows 1.11.4 (1835)
Apr 01 9:15:13 AM: Running on Microsoft Windows 11 Pro 64 bit
Apr 01 9:15:13 AM: Running on .NET Framework Version 4.8.09032.533320
Apr 01 9:15:13 AM: Checking reachability status of connection...
Apr 01 9:15:14 AM: Connection is reachable. Starting connection attempt.
Apr 01 9:15:14 AM: Interface Type: ViscTunTap
Apr 01 9:15:14 AM: Bringing up interface...
Apr 01 9:15:14 AM: Note: --cipher is not set. OpenVPN versions before 2.5 defaulted to BF-CBC as fallback when cipher negotiation failed in this case. If you need this fallback please add '--data-ciphers-fallback BF-CBC' to your configuration and/or add BF-CBC to --data-ciphers.
Apr 01 9:15:14 AM: Current Parameter Settings:
Apr 01 9:15:14 AM:   config = 'stdin'
Apr 01 9:15:14 AM:   mode = 0
Apr 01 9:15:14 AM:   show_ciphers = DISABLED
Apr 01 9:15:14 AM:   show_digests = DISABLED
Apr 01 9:15:14 AM:   show_engines = DISABLED
Apr 01 9:15:14 AM:   genkey = DISABLED
Apr 01 9:15:14 AM:   genkey_filename = '[UNDEF]'
Apr 01 9:15:14 AM:   key_pass_file = '[UNDEF]'
Apr 01 9:15:14 AM:   show_tls_ciphers = DISABLED
Apr 01 9:15:14 AM:   connect_retry_max = 0
Apr 01 9:15:14 AM: Connection profiles [0]:
Apr 01 9:15:14 AM:   proto = udp
Apr 01 9:15:14 AM:   local = '[UNDEF]'
Apr 01 9:15:14 AM:   local_port = '[UNDEF]'
Apr 01 9:15:14 AM:   remote = '127.0.0.1'
Apr 01 9:15:14 AM:   remote_port = '11943'
Apr 01 9:15:14 AM:   remote_float = DISABLED
Apr 01 9:15:14 AM:   bind_defined = DISABLED
Apr 01 9:15:14 AM:   bind_local = DISABLED
Apr 01 9:15:14 AM:   bind_ipv6_only = DISABLED
Apr 01 9:15:14 AM:   connect_retry_seconds = 1
Apr 01 9:15:14 AM:   connect_timeout = 120
Apr 01 9:15:14 AM:   socks_proxy_server = '[UNDEF]'
Apr 01 9:15:14 AM:   socks_proxy_port = '[UNDEF]'
Apr 01 9:15:14 AM:   tun_mtu = 1500
Apr 01 9:15:14 AM:   tun_mtu_defined = ENABLED
Apr 01 9:15:14 AM:   link_mtu = 1500
Apr 01 9:15:14 AM:   link_mtu_defined = DISABLED
Apr 01 9:15:14 AM:   tun_mtu_extra = 0
Apr 01 9:15:14 AM:   tun_mtu_extra_defined = DISABLED
Apr 01 9:15:14 AM:   tls_mtu = 1250
Apr 01 9:15:14 AM:   mtu_discover_type = -1
Apr 01 9:15:14 AM: NOTE: --mute triggered...
Apr 01 9:15:14 AM: 221 variation(s) on previous 100 message(s) suppressed by --mute
Apr 01 9:15:14 AM: OpenVPN 2.6.12 Windows [SSL (OpenSSL)] [LZO] [LZ4] [AEAD]
Apr 01 9:15:14 AM: library versions: OpenSSL 3.0.15 3 Sep 2024, LZO 2.10
Apr 01 9:15:14 AM: Valid endpoint found: 127.0.0.1:11943:udp
Apr 01 9:15:15 AM: Outgoing Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 01 9:15:15 AM: Incoming Control Channel Authentication: Using 160 bit message hash 'SHA1' for HMAC authentication
Apr 01 9:15:15 AM: Control Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1250 tun_max_mtu:0 headroom:126 payload:1600 tailroom:126 ET:0 ]
Apr 01 9:15:15 AM: Data Channel MTU parms [ mss_fix:0 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
Apr 01 9:15:15 AM: TCP/UDP: Preserving recently used remote address: [AF_INET]127.0.0.1:11943
Apr 01 9:15:15 AM: Socket Buffers: R=[65536->65536] S=[65536->65536]
Apr 01 9:15:15 AM: UDPv4 link local: (not bound)
Apr 01 9:15:15 AM: UDPv4 link remote: [AF_INET]127.0.0.1:11943
Apr 01 9:15:15 AM: State changed to Authenticating
Apr 01 9:15:15 AM: TLS: Initial packet from [AF_INET]127.0.0.1:11943, sid=5673e861 3169940f
Apr 01 9:15:15 AM: VERIFY OK: depth=1, CN=localhost
Apr 01 9:15:15 AM: VERIFY KU OK
Apr 01 9:15:15 AM: Validating certificate extended key usage
Apr 01 9:15:15 AM: ++ Certificate has EKU (str) TLS Web Server Authentication, expects TLS Web Server Authentication
Apr 01 9:15:15 AM: VERIFY EKU OK
Apr 01 9:15:15 AM: VERIFY OK: depth=0, CN=localhost
Apr 01 9:15:15 AM: Control Channel: TLSv1.3, cipher TLSv1.3 TLS_AES_256_GCM_SHA384, peer certificate: 2048 bits RSA, signature: RSA-SHA256, peer temporary key: 253 bits X25519
Apr 01 9:15:15 AM: [localhost] Peer Connection Initiated with [AF_INET]127.0.0.1:11943
Apr 01 9:15:15 AM: TLS: move_session: dest=TM_ACTIVE src=TM_INITIAL reinit_src=1
Apr 01 9:15:15 AM: TLS: tls_multi_process: initial untrusted session promoted to trusted
Apr 01 9:15:15 AM: State changed to Connecting
Apr 01 9:15:15 AM: SENT CONTROL [localhost]: 'PUSH_REQUEST' (status=1)
Apr 01 9:15:15 AM: PUSH: Received control message: 'PUSH_REPLY,comp-lzo no,route 172.18.0.0 255.255.0.0,dhcp-option DOMAIN herma.test,dhcp-option DOMAIN shorten.test,dhcp-option DOMAIN email.test,dhcp-option DOMAIN client.test,dhcp-option DOMAIN farmherma.test,dhcp-option DOMAIN jungleherma.test,route 192.168.255.1,topology net30,ping 2,ping-restart 15,dhcp-option DNS 172.18.0.5,ifconfig 192.168.255.6 192.168.255.5,peer-id 0,cipher AES-256-GCM'
Apr 01 9:15:15 AM: OPTIONS IMPORT: --ifconfig/up options modified
Apr 01 9:15:15 AM: OPTIONS IMPORT: route options modified
Apr 01 9:15:15 AM: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Apr 01 9:15:15 AM: interactive service msg_channel=0
Apr 01 9:15:15 AM: ROUTE_GATEWAY 192.168.11.1/255.255.255.0 I=49 HWADDR=b4:45:06:3e:a3:9a
Apr 01 9:15:15 AM: Awaiting adapter to come up...
Apr 01 9:15:19 AM: Virtual Adapter Version: 0.8.2.1019
Apr 01 9:15:24 AM: TAP-WIN32 device [HERMA] opened: \\?\root#net#0004#{adda4c48-c32e-4ef6-9602-b3252f082583}, index: 27
Apr 01 9:15:24 AM: TAP-Windows MTU=1500
Apr 01 9:15:25 AM: Waiting for DNS Setup to complete...
Apr 01 9:15:26 AM: Successful ARP Flush on interface [27] {69EA3B42-5A56-47C1-9581-262C3470E8B8}
Apr 01 9:15:26 AM: do_ifconfig, ipv4=1, ipv6=0
Apr 01 9:15:26 AM: Data Channel MTU parms [ mss_fix:1399 max_frag:0 tun_mtu:1500 tun_max_mtu:1600 headroom:136 payload:1768 tailroom:562 ET:0 ]
Apr 01 9:15:26 AM: Outgoing Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr 01 9:15:26 AM: Incoming Data Channel: Cipher 'AES-256-GCM' initialized with 256 bit key
Apr 01 9:15:26 AM: Data Channel: cipher 'AES-256-GCM', peer-id: 0, compression: 'stub'
Apr 01 9:15:26 AM: Timers: ping 2, ping-restart 15
Apr 01 9:15:28 AM: TEST ROUTES: 2/2 succeeded len=2 ret=1 a=0 u/d=up
Apr 01 9:15:28 AM: Route addition via service succeeded
Apr 01 9:15:28 AM: Route addition via service succeeded
Apr 01 9:15:28 AM: Initialization Sequence Completed
Apr 01 9:15:28 AM: DNS set to Split, report follows:
Server: 1.1.1.1:53, Lookup Type: Any, Domains: None
Server: 8.8.8.8:53, Lookup Type: Any, Domains: None
Server: 172.18.0.5:53, Lookup Type: Split, Domains: herma.test., shorten.test., email.test., client.test., farmherma.test., jungleherma.test.
Apr 01 9:15:28 AM: State changed to Connected

Is there any way we can checkout if the issue is coming from Viscosity or an incompatibility with CrowdStrike?

Aaron · 15 June 2025 23:44

Hi jesteban,

Thank you for including your logs. It looks like Crowdstrike may be interfering with bringing the VPN network adapter online:

Mar 27 6:00:10 PM: Awaiting adapter to come up...
Mar 27 6:00:20 PM: TAP-WIN32 device [HERMA] opened: ...

Generally bringing the adapter up should be near instant, however in this case we can see from the time difference in the log messages that it’s taking 10 seconds. 10 seconds is also how long Viscosity will wait for any Windows filters attaching to the network adapter to come online before forcibly continuing. So from your description it sounds likely here that Crowdstrike is trying to attach something to the virtual VPN network adapter, and it’s getting stuck or failing.

You can try increasing the Ping Restart value for your VPN connection to see if the problem is recoverable. Try setting it to 60 seconds and see if the VPN connection is eventually able to come online.
https://www.sparklabs.com/support/kb/article/connection-settings/#options

If it still fails, then I recommend seeing whether you can exclude Crowdstrike from trying to attach to the VPN network interface.

Regards,
Aaron

jesteban · 11 September 2025 15:25

Hi there, sorry it took so long to reply. I tried everything with the Crowdstrike people, from exclusions to getting system logs and network captures, and they don’t see anything that indicates that Crowdstrike is actually blocking the connection. We even tried tests to make sure we could watch it happen.

We think the problem could be related to how Viscosity uses OpenVPN underneath, and that somehow it conflicts with CrowdStrike, but no idea how. I’m also thinking that the local vpn is being generate in a weird way. Since the connection is a local VPN to a docker in localhost, I wouldn’t be surprised if the problem was there, on how Viscosity resolves the localhost address.

Any suggestions in how to proceed? We are running out of ideas…

Aaron · 12 September 2025 07:45

I’m afraid we don’t really have any other suggestions we can offer.

Make sure you’ve followed the suggestions in my previous post about increasing the Ping Restart time. And if that doesn’t help, also make sure you’ve debugged what could be causing the VPN network adapter to take so long to become active (again based on your description, likely a filter driver from Crowdstrike, or a different filter driver clashing with Crowdstrike, attaching to the VPN interface and becoming unresponsive).

Your logs indicate that the VPN connection is initially establishing, but it is then dropping out. This could be due to the slow network adapter setup and lower-than-default Ping Restart time, or it could be that the VPN traffic is being blocked after the VPN network adapter is activated.

You could potentially look at trying a different endpoint security package and see whether you’re able to get the same security features without it interfering with your local Docker/VPN setup.

Regards,
Aaron

phosjon · 20 October 2025 10:35

Did you ever find a solution to this? I’m seeing a long hang connecting to my Sophos XGS with VIscosity, and I’m also running CrowdStrike Falcon. Eventually it connects for me though.

Oct 17 5:09:44 PM: Awaiting adapter to come up…
Oct 17 5:10:05 PM: Virtual Adapter Version: 0.9.2.1021
Oct 17 5:10:07 PM: Third-party filters attached to network interface: “Npcap Packet Driver (NPCAP) (INSECURE_NPCAP)”.
Oct 17 5:10:20 PM: TAP-WIN32 device [sslvpn-lusky-client-config] opened: \?\root#net#0003#{adda4c48-c32e-4ef6-9602-b3252f082583}, index: 13
Oct 17 5:10:24 PM: Waiting for DNS Setup to complete…
Oct 17 5:10:26 PM: Successful ARP Flush on interface [13] {7C9DFC35-0394-4864-8BBB-7CD00F8DA66F}
Oct 17 5:10:26 PM: Data Channel: cipher ‘AES-256-GCM’, peer-id: 0
Oct 17 5:10:26 PM: Timers: ping 45, ping-restart 180, inactive 900 7680
Oct 17 5:10:26 PM: Protocol options: protocol-flags cc-exit tls-ekm
Oct 17 5:10:31 PM: TEST ROUTES: 5/5 succeeded len=5 ret=1 a=0 u/d=up
Oct 17 5:10:36 PM: Route addition via service succeeded
Oct 17 5:10:36 PM: Route addition via service succeeded
Oct 17 5:10:36 PM: Route addition via service succeeded
Oct 17 5:10:36 PM: Route addition via service succeeded
Oct 17 5:10:36 PM: Route addition via service succeeded
Oct 17 5:10:36 PM: Initialization Sequence Completed
Oct 17 5:10:36 PM: DNS set to Split, report follows:

Aaron · 21 October 2025 13:47

Hi phosjon,

It’s worth making sure the issue isn’t being caused by the Npcap driver in this instance:

Oct 17 5:10:07 PM: Third-party filters attached to network interface: “Npcap Packet Driver (NPCAP) (INSECURE_NPCAP)”.

This is bundled with tools like Wireshark, but often isn’t removed when these tools are uninstalled. This can lead to old versions that may cause issues to stick around. I don’t believe there are any known issues with the latest Npcap version and Viscosity, but it’s probably worth uninstalling it just to rule it out before looking more closely at other software such as CrowdStrike.

Regards,
Aaron

jesteban · 4 November 2025 10:24

No, I’m afraid the problem persists and we don’t know what else to do. We even had a call with CrowdStrike to debug the issue, check the logs and such, but they didn’t find a thing. It’s a nuance, but we might need to look for another VPN client.