File Copies Slump When the VPN Connects: SMB Multichannel

A file copy between two Windows machines is quick until both of them join the same VPN, and then it collapses while a throughput test across the same pair still reports close to line rate. That gap is the diagnosis: the link is fine and something is choosing a worse path for the transfer itself. The something is usually SMB3 Multichannel, doing precisely what it was designed to do. Take the extra channel out of the picture and the copy returns to the physical link.

The Symptom Waits on Its Slowest Channel

Multichannel lets one SMB session use several TCP connections, one per suitable address pair between client and server. When both machines sit on the LAN and on the same tunnel, Windows can pair the LAN addresses and the tunnel addresses and treat both pairs as usable. The session ends up with more channels than the physical link needs, and one of them is far slower.

It does not fail. It waits, because the session cannot finish faster than its slowest channel.

That is why a bandwidth test can look healthy while a copy crawls: a single-stream measurement may pick one path, while the transfer was spread across two. Read the channel list before changing any adapter setting, and read it while the copy is still running, because an idle session shows nothing. What you write down should name the interface behind each channel, not just how slow the result felt.

Confirm That a Second Channel Exists

Two cmdlets answer the question directly. The connection list shows the channels in use, and the session summary shows the connection itself. Run both during the slow copy.

Get-SmbMultichannelConnection
Get-SmbConnection

Look for more than one row marked as selected for the same server, then resolve the client address in the suspicious row. If that address belongs to the tunnel adapter, the second path is real and confirmed. If every row belongs to the physical interface, Multichannel is not your problem and the copy is slow for an unrelated reason. Do that confirmation first, because the repair is disruptive enough to deserve a minute of evidence.

Get-NetIPAddress -IPAddress 10.20.30.44

Addresses here are placeholders. Substitute whatever your own output reports, since copying an address from a blog is how a working command becomes a confusing error message.

Remove the Tunnel From SMB, Then Measure Again

Disabling Multichannel is the quickest way to confirm the diagnosis, and it is reversible. Apply the client setting on the machine doing the copy and the server setting on the machine hosting the share, because either side alone can keep the extra channel alive. The change applies to new connections rather than existing ones, so an open session survives it. Reboot both machines, or at least close every handle to the share, before measuring anything.

Set-SmbClientConfiguration -EnableMultiChannel $false -Force
Set-SmbServerConfiguration -EnableMultiChannel $false -Force

Confirm the new state, then look at what the server now advertises to clients.

Get-SmbClientConfiguration | Select-Object EnableMultiChannel
Get-SmbServerNetworkInterface | Format-List *

The tunnel interface should drop out of that advertised list. If it does not, the setting landed on the wrong endpoint or an old session is still open. If file sharing simply must not use the tunnel, unbind the server component from that adapter instead, which leaves the tunnel usable for every other service.

Get-NetAdapterBinding -Name "OpenVPN Data Channel Offload"
Disable-NetAdapterBinding -Name "OpenVPN Data Channel Offload" -ComponentID ms_server

Prefer the LAN Path Without Pretending It Deletes Channels

An interface metric tells Windows which path to prefer for new connections. It does not remove a channel that Multichannel has already decided to open. Raising the tunnel's metric is still worth doing, because it keeps unrelated traffic off the slow path and makes the preferred route predictable, but it is a nudge rather than a filter.

Get-NetIPInterface | Sort-Object InterfaceMetric | Select-Object InterfaceAlias, InterfaceMetric
Set-NetIPInterface -InterfaceAlias "OpenVPN Data Channel Offload" -AutomaticMetric Disabled -InterfaceMetric 1000

Copy the alias out of that output instead of typing it, because some installs localise the adapter name and the English string will not match.

Then measure both numbers again: the file copy and a throughput test across the same pair. If the copy recovers while the throughput test was never slow, Multichannel was the cause and you can stop. If both collapse, the tunnel is the bottleneck and Multichannel only amplified it. If the copy stays slow while both paths look correct, the remaining problem lives in the share, the storage or a filter driver, which is a different investigation.