Quick Answer
Check if the target service is actually listening on that port (netstat -an | find "LISTENING"), then verify Windows Firewall allows inbound traffic on that port. If it's a remote server, make sure the service isn't bound to localhost only.
What This Error Actually Means
You're seeing 0xC0000236 because the remote machine got your SYN packet, checked its firewall rules, and said "nope, not letting you in." This isn't a timeout where the packet got lost—the remote box actively refused the connection. I've seen this most often with Remote Desktop (port 3389) after a Windows update reset firewall rules, or with SQL Server when someone forgot to enable TCP/IP in SQL Server Configuration Manager.
Last month, a client called panicking because their entire remote workforce couldn't RDP into the office server. Turned out a Windows security patch had reset the firewall rules. Their firewall was wide open for everything except Remote Desktop—which was now blocked. That's your typical 0xC0000236 scenario.
Fix Steps – Starting With the Likeliest Culprit
Step 1: Verify the Service Is Actually Listening
On the remote machine (the one you're connecting to), open Command Prompt as admin and run:
netstat -an | find "LISTENING"Look for the port you're trying to connect to. If you don't see 0.0.0.0:3389 (or whatever port) in the list, the service isn't running or isn't bound correctly. For RDP, check that "Remote Desktop Services" is running (services.msc). For SQL Server, open SQL Server Configuration Manager, go to SQL Server Network Configuration, and make sure TCP/IP is enabled.
Step 2: Check Windows Firewall
Run the following from an admin Command Prompt:
wf.mscGo to Inbound Rules. Find the rule for your service (e.g., "Remote Desktop - User Mode (TCP-In)"). If it's disabled, enable it. If it doesn't exist, create a new rule: Port, TCP, specific local port (e.g., 3389), Allow the connection, apply to all profiles (Domain, Private, Public).
A quicker test: temporarily disable the firewall entirely (right-click the network icon, Windows Defender Firewall, turn it off for all profiles). Only do this for testing—if the connection works with the firewall off, you know it's a firewall rule issue. Turn it back on and fix the rule.
Step 3: Check If the Service Is Bound to Localhost
Some services (like certain database instances or dev web servers) only bind to 127.0.0.1. Run netstat -an again. If you see 127.0.0.1:1433 instead of 0.0.0.0:1433, the service won't accept remote connections. Fix it in the service's configuration (e.g., SQL Server Configuration Manager, IP Addresses section, set "TCP Dynamic Ports" or assign a static port and set "Listen All" to Yes).
Alternative Fixes If the Main Steps Fail
- Reset Windows Firewall to defaults – run
netsh advfirewall resetfrom an admin prompt, then reconfigure your allowed apps. This nuked the problem for that client I mentioned earlier. - Third-party firewall or antivirus – Norton, McAfee, Kaspersky, and even some corporate AV suites (like CrowdStrike or SentinelOne) have their own firewall modules. Temporarily disable only the firewall component of the AV to test.
- Check the remote machine's routing – if you're connecting across a VPN or different subnet, make sure the remote machine's default gateway is set correctly.
route printandpingthe remote IP to confirm it's reachable. - Check if the port is blocked upstream – if you're on a corporate network, a network firewall or router could be blocking the port. Try connecting from a different network (phone hotspot) to rule this out.
Prevention Tip
Before you make a service remotely accessible, test it locally first. Connect from localhost on the same machine. If that works, then configure the firewall and test from another machine on the same LAN. Only then open it to the internet. And document every firewall rule you create—future you will thank present you when a Windows update resets everything.
Pro tip: For RDP, use a non-standard port (like 3390) to dodge script kiddies. Then update your firewall rule and client connection accordingly.