SMB Multichannel Over a VPN: What the Client Actually Uses
SMB Multichannel over a VPN adds few channels: read the client interfaces, selected connections and SMB dialect before blaming the tunnel for slow files.
Slow file access over a VPN invites the Multichannel setting as a fix, and the setting often has nothing to work with. A single virtual adapter without RSS cannot fan traffic across several channels, no matter how the checkbox reads. What matters is the capability SMB sees on both endpoints, not the specification of the laptop's physical NIC. The walkthrough below starts at an active session and works back to the adapter layout.
Start from the session, not from the NIC spec
Confirm first that the session can use Multichannel at all. The feature belongs to SMB3, so an older dialect negotiated with an appliance or a legacy server rules it out before any adapter question matters. Then confirm which server the client actually connected to, because a name that resolves to a different node than the one you are inspecting produces a convincing but irrelevant result.
Get-SmbConnection
Get-SmbClientConfiguration | Select-Object EnableMultichannel
Get-SmbClientNetworkInterfaceThe first command names the dialect, the server and the share in one line. The second shows whether the client has the feature enabled, and the third lists the interfaces SMB knows about with their reported capabilities. A virtual adapter that reports no RSS and no RDMA is telling you what the layout can become.
If the dialect is not SMB3, stop and fix that question first. Every later command will otherwise describe a feature that cannot engage.
Read the client interfaces honestly
SMB does not care which adapter carries your default route; it enumerates the interfaces it can use and evaluates each one. A laptop with Wi-Fi, Ethernet and a VPN adapter may present three interfaces, and only one of them may be reachable for the server you are talking to. The others are candidates, not channels.
Read the RSS and RDMA columns rather than the link speed column. A virtual adapter commonly reports a high nominal speed with no RSS capability, and the nominal speed describes the virtual link rather than the path through the internet. Neither number tells you how many channels the session uses.
If the adapter shows no RSS capability, the supported fix belongs to the VPN vendor's driver, not to the physical NIC's advanced properties. Ticking an RSS box on the hardware adapter changes nothing about what the virtual adapter exposes to SMB.
Separate selected channels from discovered candidates
The connection list is the part most often misread. With unselected candidates included, the output shows everything SMB considered, which is not the set of channels carrying data. Read the selected flag and the channel count for the specific client and server interface pair you care about.
Get-SmbMultichannelConnection -ServerName files.lab.example -IncludeNotSelected
Get-SmbMultichannelConnection -ServerName files.lab.example | Format-List *Substitute your own server name. The second form prints the properties of the selected connections, including the interface indices and the current channel count, which is the number that matters. Several discovered addresses on one adapter are still one adapter.
A discovered address can also be unusable through the VPN policy: it may be a local subnet address the tunnel does not carry, or an address the server only serves on a different network. SMB lists it as a candidate because the interface exists, not because the path works.
What the VPN adapter does to the layout
Three layouts are worth telling apart, because only two of them can produce more than one channel. A single non-RSS adapter yields one channel. A single RSS-capable adapter can spread connections across cores. Multiple usable adapters can produce several channels even without RSS, which is the configuration people forget when they assume RSS is mandatory.
| Layout SMB sees | Channels possible |
|---|---|
| One adapter, no RSS | One |
| One adapter with RSS | Several, spread across cores |
| Two or more usable adapters | Several, one path per adapter |
| Several adapters behind one tunnel | Several, one shared bottleneck |
The last row is the one that matters over a VPN. Channels that all enter the same encrypted tunnel share the tunnel's throughput, the gateway's CPU and the WAN link. Adding a channel there redistributes work without adding capacity, and the measurement will show it.
Keep signing and encryption enabled while you compare, because turning them off changes the thing you are measuring. A performance result that depends on disabling a security setting is not a result you can deploy.
Measure the workload that is actually slow
Name the workload before you change anything: one large sequential copy, many small files in one directory, or an application that opens and closes handles. Multichannel can help the first case when real independent paths exist, and it does very little for the third, because the cost there is dependent round trips rather than bandwidth.
Capture a baseline with the current layout, change one thing, and capture again with the same file set and the same time of day. Record the selected path count alongside the number, so a later reader can tell whether the change altered the layout or only the load.
If the channels did not change, the performance question is somewhere else: the tunnel's encryption overhead, the latency of the path, or the server's own disk and CPU. Those are worth measuring before another adapter is added to a laptop that already has enough of them.