VPN Off, Still Slow: Check the Adapter Bindings

The client says disconnected, the tunnel interface is gone, and everyday traffic is still slower than before the VPN was installed. One explanation is a filter component that stayed bound to the physical adapter after the tunnel closed. That is a lead worth checking, not a verdict: the same slowness can come from a driver version, an offload setting or a second client's component. Inventory what is actually attached before changing anything.

Name the component, record its state, then change one thing.

Separate the Tunnel From the Binding

A VPN interface and a filter driver are different objects. The interface disappears when the tunnel closes; a filter attached to the physical adapter is installed in the network stack and can remain enabled regardless of tunnel state. Users see one symptom, and the operating system holds two unrelated pieces of state.

That distinction is why unplugging the client or deleting the VPN profile often changes nothing. The interface is the visible object. The binding sits further down the stack and outlives it.

Inventory the Exact Component

List the bindings on the adapter that carries the slow traffic, using its real name rather than a generic guess. Record the component ID and enabled state, then compare the physical adapter with the VPN interface and any other virtual adapters in the list.

Version information belongs in the same record, because two machines showing a similar display name can be running different drivers. A vendor can also ship a new filter component under an old display name. Compare identifiers rather than labels.

Get-NetAdapterBinding -Name 'Ethernet' -AllBindings | Select-Object DisplayName,ComponentID,Enabled
Get-NetAdapter | Format-Table Name,InterfaceDescription,DriverVersion,Status
Get-NetAdapterStatistics -Name 'Ethernet'
pnputil /enum-drivers | Select-String -Pattern 'vpn|filter|ndis' -Context 0,2
driverquery /v | Select-String -Pattern 'vpn|filter'

Write down the adapter name, the component ID, the driver version and the VPN client version. Without those four values the next comparison is guesswork. Attach them to the ticket so a later run can be compared with this one.

Change One Approved Thing and Repeat

Build a baseline with the same workload, destination and access network. Note whether the VPN is disconnected, whether the suspect binding is enabled, and whether a second VPN client is installed, because two clients can each leave components behind.

If the vendor supports toggling that binding for diagnosis, disable only that component on that adapter, repeat the identical workload, and restore the original state. A before-and-after pair from one variable is worth more than a fresh install of everything. If the result is ambiguous, restore the original state before trying the next hypothesis. Two changes at once produce a number nobody can attribute.

Then reconnect and check the VPN still works, including any policy the client is supposed to enforce. A change that improves browsing while breaking the tunnel's own enforcement has traded one fault for another, and that regression belongs in the record.

Stay on the Vendor's Supported Path

Filtering implementations change between product generations. Some vendors now document a Windows Filtering Platform path where earlier releases used a different driver family, so a registry recipe from an old forum thread can be actively wrong for the version installed.

Check the installed inventory and the active path separately, because choosing a newer mode does not prove the older component is gone. When cleanup is needed, run the vendor's supported removal or update process and repeat the binding inventory afterwards.

Keep the evidence narrow: adapter, component, versions, the controlled comparison and the VPN regression result. That supports a driver or compatibility conclusion without turning every slow connection into an MTU experiment or a claim that all VPN clients behave alike.