I was asked yesterday to investigate an issue where client PCs were getting disconnect messages from a share on a virtualised server.
It was thought that there was some problem with the virtual switch, and/or the VirtualConnect config of the blade enclosure.
A network capture was included, as was a visio diagram of the network configuration, which was very nice to have! It’s great to deal with experienced techies who know you’re going to need some background material, and think to include it with the request for help 🙂
What struck me as odd when looking at the capture was that the offending RST packets always appeared to coincide with a new TCP session being set up to port 445. ie New TCP session always followed by a RST of an old one, two new TCP sessions -> 2 RST of old connections.
A bit of digging pulled up this link, something I’d never come across before. Basically, SMBv1 does not support Hide NAT. It regards a connection between 2 IPs as a single client and a single server, and closes down any old connections between those two IPs whenever a new connection is made.
The main workaround is described in the link, namely disabling communications over port 445 for Windows XP. This forces it to use NetBIOS over TCP/IP. Woo-hoo
Windows Vista/7/8 talking to Windows 2008 Server and above can use SMBv2 which was written to cope with Hide NAT.
Testing so far has shown this workaround for Windows XP to be functional.
Anyway, chalk another issue down as “nowt to do with VMware” 😉