0

I have a bunch of servers and a file share set up on a remote HNAS. The file share is set up to use SMB 3.1.1 and the servers are all Windows Server 2019. 5 out of 6 servers connects just fine to share, but the sixth all of a sudden decided that enough was enough and stopped communicating.

I've tried connecting via Telnet on port 445 to make sure there are no connectivity issues, it works fine.

Windows File Explorer just gives me a "Windows cannot access \thenas\myshare"

If I try running a net view in the command prompt I get a System Error 53.

So, I decided to install Wireshark on two servers and I see something a bit weird.

On the server that CAN connect The packet flow is like this: Working connection

And then on the node that refuses: enter image description here It does this song and dance routine three times (so one more time than shown in the screenshot) then gives up and Windows returns back with an error.

The Red redactions are the IP address of the server and the green redactions are the IP of the NAS.

I've checked the SMB Negotiate Protocol Request and it is almost identical in both cases (apart from different source IP, target IP and time). It's just that in the case where it WORKS it sends a SMB Negotiate Protocol Response, and in the case where it doesn work, it just gives me a FIN ACK packet.

I've checked the local security policies and as I said before, I've tried telnet on port 445 to the server, both works.

The other 5 servers are set up in the exact same way (servers are in Azure and deployed using the same script), they use the same route to the HNAS as the one that has just decided to stop working.

The misbehaving server is just fine connecting to other file shares using SMB 3.1.1 but not this one all of a sudden, for some odd reason.

Has anyone seen this kind of behavior before and have any ideas where to look?

JaggenSWE
  • 275

1 Answers1

0

Turns out, after much digging around that one of the later versions of the HNAS OS implemented some "auto barring" function that would blacklist an IP address if sensed too many failed NTLM logon attempts during a given time interval (not sure about the specifics). Clearing the list and disabling the feature solved the problem.

JaggenSWE
  • 275