Testing network connectivity

One of the difficulties of working in a tightly controlled datacenter environment is establishing whether something isn’t working because of firewall rules. With most things, you can just test TCP connections using the telnet client, which is a nice simple command line utility that I generally include in Windows installs purely for that purpose.

With UDP it’s a little more difficult, and with trying to confirm that firewalls were blocking UDP/1434 between MS SQL Server installations in two sites, I’ve ended up with the following.

• Wireshark installed and running on both servers
• Powershell used with the following function Test-Port

With wireshark running and a capture filter for port 1434, I have then been running test-port -comp destserver -port 1434 -udp -udptimeout 10000 and checking both wireshark captures.

While the test-port reports success (UDP is connectionless after all, so a send is generally going to be accepted) , the wireshark tells a different story, of packets leaving and not arriving. One for the firewall guys to resolve.

I also discovered while looking into this, that on linux there’s a way of testing both TCP and UDP connections from the commannd line using special files:

/dev/tcp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a TCP connection to the corresponding socket.

/dev/udp/host/port
If host is a valid hostname or Internet address, and port is an integer port number
or service name, bash attempts to open a UDP connection to the corresponding socket.

For example:

rich@www:~$ cat < /dev/tcp/localhost/22
SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
^C

See also my post here on testing network connectivity from ESXi.

SMBv1 and Hide NAT

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” 😉