Why an SMB copy slows down when both PCs join the VPN

A file copy between two Windows machines on a gigabit LAN drops to a crawl the moment both of them connect to the same VPN, while a throughput test between the same pair still reports close to line rate. The link is not the problem and neither is the disk. SMB3 Multichannel has quietly added a second TCP connection that runs over the tunnel, and the copy waits on whichever channel is slowest. Removing that path from SMB brings the LAN rate back.

One share can ride several TCP connections

Multichannel lets a client open independent connections to one server, one per suitable pair of addresses. On a plain LAN there may be a single pair, so nothing surprising happens. Add a VPN adapter on both machines and Windows sees a second pair, tunnel address to tunnel address, and opens a channel across it.

That channel is encrypted, shares the CPU with the tunnel and crosses the same WAN link as everything else. A copy that would have used the LAN alone now has a slow member in the set, and SMB does not quietly drop it.

A throughput test pinned to the LAN address still looks healthy, which is exactly why the two measurements disagree so sharply.

Prove the tunnel channel exists before changing anything

Run the queries on the client while a copy is in progress, because a channel list is only interesting when it is live.

Get-SmbMultichannelConnection | Where-Object Selected -eq $true | Format-Table ServerName, ClientIPAddress, ServerIPAddress
Get-SmbConnection | Format-Table ServerName, Dialect, NumOpens

More than one selected row for the same server is the confirmation you need. Resolve the client address of the suspicious row to an interface. If that alias is the VPN adapter, the channel is real rather than a stale entry.

Get-NetIPAddress -IPAddress 10.8.0.6 | Format-List IPAddress, InterfaceAlias

Addresses differ on every machine, so read the ones your own output reports instead of typing the examples above.

Take the tunnel out of SMB and restart both ends

Turning Multichannel off is a change on both the client and the server, and doing it on one side leaves the other free to keep offering the interface. Existing channels survive the setting, so plan a restart instead of expecting the next copy to behave.

Set-SmbClientConfiguration -EnableMultiChannel $false -Force
Set-SmbServerConfiguration -EnableMultiChannel $false -Force
Get-SmbClientConfiguration | Select-Object EnableMultiChannel

After the reboot, list the interfaces the server offers for SMB. The tunnel adapter should be gone from that list. If it is still present, the setting landed on the wrong endpoint or an old session is still open.

Get-SmbServerNetworkInterface | Format-List Name, InterfaceAlias, LinkSpeed

When the goal is narrower than disabling Multichannel everywhere, unbinding the server component from the tunnel adapter stops sharing over it while leaving the rest of the VPN alone.

Get-NetAdapterBinding -Name "<vpn adapter>" -ComponentID ms_server
Disable-NetAdapterBinding -Name "<vpn adapter>" -ComponentID ms_server

Prefer the LAN and measure the same way twice

An interface metric does not remove a channel, but it steers new connections toward the physical link and keeps unrelated traffic off the tunnel. Copy the alias from the output rather than typing it, because it is localized on some installs.

Get-NetIPInterface | Sort-Object InterfaceMetric | Select-Object InterfaceAlias, InterfaceMetric
Set-NetIPInterface -InterfaceAlias "<vpn adapter>" -AutomaticMetric Disabled -InterfaceMetric 9000

Then repeat both measurements: the file copy and a single-stream throughput test. If the copy recovers while the throughput test is unchanged, the tunnel was never the bottleneck. If both collapse, the VPN path is the limit and Multichannel only made it visible. Compare against a copy taken before the VPN was connected, because that is the only baseline that isolates the change.

Disabling Multichannel costs throughput on servers that genuinely offer several fast paths, so turn it back on when the VPN leaves the picture. Record which adapter you changed, because the next person will find the setting and not the reason.