RDP Connection Problem: Can't Connect to Windows Server
RDP connection troubleshooting guide: Path.net firewall rules, Default Block, creating a filter rule for RDP port, and step-by-step troubleshooting.
Table of Contents
Introduction
If you can't connect to your Windows Server via RDP (Remote Desktop Protocol), the most likely cause is that no filter rule has been created for the RDP port (3389) in the Path.net firewall.
On REXE Technology servers, the Path.net DDoS protection system works automatically based on rules. When an IP has no rules at all, all ports are open. However, if your IP has at least one rule, the system automatically applies Default Block and only the allowed ports stay open. For RDP access, you need to create a filter rule that opens the RDP port (3389).
This guide follows the same logic as the SSH troubleshooting guide. The only difference is the port number: SSH → 22, RDP → 3389.
The Cause
When your IP has rules, Path.net automatically applies Default Block; in that case, if there is no rule for the RDP port (TCP 3389), it is blocked:
RDP Connection Request → Path.net Firewall
→ Rule for port 3389 exists?
→ No → Connection blocked (timeout)
→ Yes → Connection allowed
Solution: Create a Filter Rule for RDP Port
To access RDP, you need to create a port-specific filter rule via Path Panel or the Rule Management product in your customer panel. This rule only opens RDP port (3389) — all other ports remain closed with Default Block.
Steps
-
Log in to Path Panel or the Rule Management product in your customer panel
-
Click your server IP in IP Management
-
Create New Rule with the following settings:
Protocol: TCP
Destination Port: 3389
Description: RDP access
- Wait for the rule to reach propagated status (2-5 minutes)
This rule only opens TCP port 3389. All other ports remain closed with Default Block.
The rule creation screen has two modes: standard filter (you just enter protocol + port) and hard filter (Layer7 filters like TCP Symmetric). For RDP the standard mode is enough. TCP Symmetric is a hard filter that performs Layer7 filtering, and it should only be enabled for highly sensitive applications.
Rule Propagation Time
It may take 2-5 minutes for your rule to propagate to all Path.net network points. Track the rule status from the Path Panel:
- pending → Created, waiting to be sent
- synced → Sent to Path.net
- propagated → Full protection active, connection possible
- failed → Failed, retry
Even if the panel shows the rule as not yet propagated (not updated), the rule has most likely already been deployed within 2-5 minutes. The status may update with a delay due to the panel's status-check interval or the time it takes for the rule to be applied across all nodes on the Path side (except ours). This is only a visual delay in the panel; the port has in fact already been opened in the system.
Additional Checks
If you still can't connect after creating the filter rule:
1. Verify RDP is Enabled
Access the VNC/KVM console from the REXE customer panel and check:
- Server Manager → Local Server → Remote Desktop → Should be Enabled
- Services → Remote Desktop Services → Should be Running
2. Check Windows Firewall
Windows Firewall may be blocking RDP:
# Check RDP rule in Windows Firewall
Get-NetFirewallRule -DisplayName "Remote Desktop*" | Select-Object DisplayName, Enabled
# Allow RDP
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
3. Check RDP Port Number
The default RDP port is 3389. If you're using a different port:
# Check current RDP port
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name PortNumber
4. Network Level Authentication (NLA)
If NLA is enabled and the client is incompatible, the connection may be refused:
# Check NLA status
Get-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication
5. Connection Test
# Test port from your local computer
Test-NetConnection -ComputerName SERVER_IP -Port 3389
Security Recommendations
- Use strong passwords: RDP brute-force attacks are common
- Keep NLA enabled: Network Level Authentication provides additional security
- Hard filter (optional): Layer7 filters like TCP Symmetric are only needed for highly sensitive applications; for standard RDP access, protocol + port is enough
- Change the RDP port: Consider using a different port instead of the default 3389
If you changed the RDP port, don't forget to update the port in your Path Panel filter rule as well.
Related Articles
SSH Connection Problem: Can't Connect to Server
SSH connection troubleshooting guide: Path.net firewall rules, Default Block, creating a filter rule for SSH port, and step-by-step troubleshooting.
How to Run an MTR Test and Submit Results to Support
Guide to running MTR network tests with WinMTR and Linux MTR, creating ICMP filter rules, and submitting results to support. Diagnose packet loss and latency.
How to Capture Packets (PCAP) and Submit to Support
Packet capture guide using Linux tcpdump and Windows Wireshark. Create PCAP files for network analysis, troubleshoot connectivity issues, and submit to support.