I'm poring over a number of Windows 10 to SMB Server pcaps and noticing a pattern which looks like this:
Negotiate Protocol
Session Setup
Tree Connect Request Tree: \server\share
Ioctl FSCTL_QUERY_NETWORK_INTERFACE_INFO
...
It is the 4th step where I want to focus attention.
In the Response to this Ioctl Request, the Server enumerates its interfaces. In my environment, the average SMB Server has a single interface -- the one over which the current SMB is established, and so the Ioctl Response looks like this:
Out Data
- Network Interface, RSS, 1.0 Gbits/s, IPv4: a.b.c.d
However, some of our SMB Servers have multiple interfaces (typically NAS boxes):
Out Data
- Network Interface, RSS, 1.0 Gbits/s, IPv4: a.b.c.d
- Network Interface, RSS, 10.0 Gbits/s, IPv4: a.b.e.f
The existing SMB session is traversing the 10Gb interface, as we intend: we call this the 'front-end' interface of the NAS cluster. We use the 1Gb interface for management traffic: syslog, snmp, ntp, ssh/http for admins administering the box.
However, sometimes Clients will read/write files across the 10Gb interface ... and then ... start a second SMB session across the 1Gb interface. We don't want that -- it works, but we don't want client traffic traversing the dedicated management network -- I'm looking for ways to unbind SMB from these 'mgmt' interfaces.
But in the meantime, I would like to better understand why a Client might choose to do this. I am poking through MS-SMB2, and I see a technical description of FSCTL_QUERY_NETWORK_INTERFACE_INFO but no discussion of how a Client might modify its behavior based on the contents of the Response. Any ideas? Speculation?
Errata - in these pcaps, I can see our Clients & SMB Servers settling on the 3.1.1 SMB Dialect, and specifically declaring support for Leasing, Large MTU, Multi-Channel, and Persistent Handles
--sk
Stuart Kendrick