I've been struggling to establish a successful TCP handshake between my Domain Controller (Windows Server 2016) and other devices on port 445. I've checked everything I can think of: the firewall is disabled for testing, the share properties are set correctly, and the DC is listening on port 445. The 'Server' service is running and I've restarted it multiple times. I've confirmed that SMBv2 is active, but for some reason, I'm not able to get it working.
When I try accessing the netlogon share from the server using \\contoso\NETLOGON, it works just fine. However, when I attempt it from other devices, I get either 'Network Path Not Found' or 'Access Denied'. The strange part is that the DC responds to any SYN packets with RST ACK, indicating something is blocking the handshake. Using the IP address doesn't change anything, and I can't connect to the port via telnet or PowerShell from other devices either. I've exhausted typical troubleshooting resources, and Microsoft's support suggests issues with firewalls or services not running, which I've verified isn't the case. Any insights or brainstorming ideas would be really helpful!
5 Answers
What’s the current state of your domain? If you’ve recently removed any DCs or are facing replication issues, that might impact your connectivity. Any relevant errors in the event logs for DNS or Active Directory replication could give you clues too.
You might want to try connecting with the server's IP directly instead of its name, and also see if you can access the server without specifying a share (contoso). Sometimes that can help diagnose the problem. Results might give a clearer error message.
No luck—trying both the IP and contoso yielded the same 'access denied' errors. The core issue seems to be tied to the TCP handshake itself.
Have you tried resetting the SMB server configuration? The command is `Reset-SmbServerConfiguration -All`, but make sure your PowerShell is updated since you mentioned missing the cmdlet before.
I looked into that, but it seems I don't even have the cmdlet available, which is frustrating!
Just a thought, but could there be any security policies at play? Last time I faced a similar issue, my team updated the firewall settings and inadvertently enabled some SSL security that affected certain connections. It's worth double-checking those configurations!
That sounds familiar! I'm currently the only one managing the setup, which makes troubleshooting a bit of a challenge.
First off, have you looked into your DNS settings? Sometimes issues with hostname resolution can cause these kinds of path errors. Ensure the server’s name resolves correctly and that the correct IP is mapped in your network settings.
I checked DNS and everything is good on that end. The server name correctly maps to the IP address, and connectivity seems solid except for port 445.
The domain health is actually good, but I did remove a 2008 DC not long ago. I’m currently trying to migrate from FRS to DFSR, and I need proper access to facilitate replication.