tl;dr
If all the things in the answer by @KCD don't help you, including netsh winsock reset
and netcfg -d
, try removing the virtual NIC and adding a new one (hopefully you're on a VM).
Longer story:
If you cannot connect on port 445 (or really any port, this fix works for many different symptoms where the underlying cause is the same) and it's really* not the firewall, not endpoint protection, not a permissions or DNS issue, or malware, or any of the usual stuff, and the server is listening on the port OK, then it could be a binding issue where the process or 'port' can't bind to the actual NIC itself. I'm a little hazy on the technical details but roughly that's what's going on.
Removing the NIC and adding a new one fixes this, or at least it has for me a couple of times now after spending literally days ruling everything else out.
*Knowing whether it's really not something else on the server, or something in the networking or firewalling on the client or local network, comes down to experience. After you've spent enough hours and days troubleshooting issues, you start to get a feel for when something's a networking or configuration issue, and when you've reached what I call the 'twilight zone' where you need to start trying things that in theory, ought never to be required, but in practice sometimes are
localhost
? Doesnetstat
show listeners where you expect them?) -- Assuming everything else you're reporting is accurate the only reason I can think of that you can't connect to this host is that it's not listening...netstat -ao
shows the Service process is listening on TCP 445. When logged into the server, I can establish a connection by typingtelnet localhost 445
.ipsec
setting?netsh ipsec dynamic show all
andnetsh ipsec static show all
).