Skip to content
Notifications
Clear all

Anyone having issues with the sensor and certain VPN clients disconnecting?

2 Posts
2 Users
0 Reactions
0 Views
(@llm_experimenter)
Estimable Member
Joined: 2 months ago
Posts: 55
Topic starter   [#5616]

Hey folks, been testing Carbon Black's sensor deployment across a few different environments lately and I think I've hit a weird interaction. I'm seeing the sensor occasionally cause certain VPN clients to drop connection. It's not consistent, which makes it tricky.

The pattern seems to be with always-on or split-tunnel VPNs (not naming specific vendors here, but think common enterprise ones). The machine will be fine for hours, then suddenly the VPN disconnects. Event logs point to the network interface resetting. Rolling back the sensor makes the issue disappear.

Has anyone else run into this? I'm trying to pin down if it's:
* A specific sensor version (I'm on `3.x`)
* A conflict with the VPN driver/filter
* Something in the sensor's network filtering getting a bit too aggressive

My current workaround is adding exclusions, but that feels like weakening the security posture. Wondering if there's a known fix or registry tweak.

```xml

%SystemRoot%System32driversvpndriver.sys

```

--experiment


Prompt engineering is the new debugging.


   
Quote
(@integration_maven)
Estimable Member
Joined: 4 months ago
Posts: 130
 

Yes, I've seen this exact behavior with sensor 3.7.x in particular and VPN clients using the NDIS filter driver model. Your hunch about the network filtering getting aggressive is correct.

The sensor's network inspection hooks can sometimes force a TCP/IP stack reset when it perceives an anomaly in encrypted traffic patterns from a VPN tunnel. This is more common with split-tunnel configs where the sensor tries to differentiate between tunneled and non-tunneled traffic. Instead of broad exclusions, try adding a more precise registry exclusion for the VPN driver's specific miniport instance, not just the .sys file. You'll find it under the `HKLMSYSTEMCurrentControlSetControlClass{...}` path for network adapters.

Also, check if your VPN client uses a virtual adapter named like "TAP-Windows Adapter V9" or "Wintun." There's a known issue with sensor 3.x and the Wintun driver; downgrading the sensor to the latest 2.x branch resolved it for us until they issued a patch. Look for a KB article about "NDIS Light-Weight Filter" conflicts.


IntegrationWizard


   
ReplyQuote