Securing Windows RDP with Cloudflare Tunnels and Zero Trust Access: Eliminating Port 3389 Exposure, Brute-Force Attacks, and Inbound Firewall Holes: Sysadmin Runbook

Exposing default Remote Desktop Protocol (RDP) port 3389 directly to the public internet is one of the highest cybersecurity liabilities for enterprise infrastructure and remote workstations^[1]. Automated vulnerability scanners, Shodan crawlers, and dictionary attack bots target public IPv4 addresses continuously, generating tens of thousands of failed login attempts per hour. These persistent attacks exhaust server CPU resources, lock legitimate administrative accounts under Windows lockout policies, and expose unpatched systems to remote code execution vulnerabilities^[1].

Historically, organizations attempted to protect RDP by altering the default listening port (e.g., from 3389 to an arbitrary high port) or deploying traditional corporate VPN concentrators. However, port obscurity provides zero protection against automated port sweeps, and legacy VPNs introduce high operational overhead, split-tunnel configuration complexities, and single points of failure across variable residential ISP connections.

Cloudflare Zero Trust and Cloudflare Tunnels (cloudflared) provide a modern zero-trust architecture that completely isolates Windows Server RDP from the public internet^[2][3]. By establishing lightweight, outbound-only encrypted connections (via QUIC and TLS 1.3) from the Windows host to Cloudflare’s global edge network, administrators can completely close port 3389 on the hardware firewall^[3]. Access is strictly authenticated via multi-factor identity providers (such as Google Workspace, Microsoft Entra ID, or GitHub) before a single TCP packet reaches the server^[2][4].

---

Architectural Comparison: Direct RDP vs. VPN vs. Cloudflare Zero Trust

Understanding how Cloudflare Tunnels transform RDP perimeter defense helps evaluate infrastructure security postures:

Security & Performance Vector	Public Port 3389 Exposure	Traditional Corporate VPN	Cloudflare Zero Trust Tunnel
Inbound Firewall Ports	Requires open public inbound TCP/UDP 3389[1].	Requires open inbound UDP/TCP ports (OpenVPN, WireGuard, IPsec).	Zero open inbound ports. Outbound-only TLS/QUIC connections to edge[3].
Brute-Force Attack Surface	Constant exposure to credential stuffing and port scanners[1].	Attack surface shifts to the VPN gateway login portal.	Zero exposure. Port 3389 is completely invisible to Shodan and Nmap[2].
Authentication Enforcement	Windows NLA only; vulnerable if weak passwords exist[1].	Pre-shared keys or separate VPN user database.	MFA / SSO enforced at edge (Google, Microsoft, SAML, WebAuthn FIDO2)[4].
Network Latency Impact	Direct path, but unprotected.	High latency if VPN concentrator is geographically distant.	Sub-10ms routing via Anycast edge routing through domestic exchange peers[2].
Client Software Requirements	Native MSTSC client only.	Heavy third-party VPN client with virtual network adapters.	Lightweight single binary cloudflared proxy listener or WARP client[2].

For enterprise operations and remote development teams requiring guaranteed throughput, unshared CPU cores, and deterministic isolation, hosting on Dedicated Servers eliminates hypervisor contention while maintaining complete zero-trust access control.

---

Step 1: Preparing Windows Server for Secure RDP & Localhost Binding

Before establishing the tunnel, verify that Network Level Authentication (NLA) is strictly enforced on the target Windows Server 2022 or Windows Server 2025 host^[1].

Open an elevated PowerShell prompt on the Windows server:

# Enable Remote Desktop
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name "fDenyTSConnections" -Value 0

# Enforce Network Level Authentication (NLA)
Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name "UserAuthentication" -Value 1

# Verify RDP service status
Get-Service -Name TermService | Select-Object Name, Status, StartType

Closing Port 3389 on Windows Firewall

Once the Cloudflare Tunnel is established, incoming RDP traffic will be routed locally from the loopback interface (127.0.0.1:3389). Block public inbound access to port 3389 across Public and Domain profiles:

# Block public WAN inbound traffic on port 3389
New-NetFirewallRule -Name "Block-Public-Inbound-RDP" `
    -DisplayName "Block Public Inbound RDP (Cloudflare Tunnel Enforced)" `
    -Direction Inbound `
    -Action Block `
    -Protocol TCP `
    -LocalPort 3389 `
    -Profile Public, Domain `
    -Enabled True

At this stage, external port scanners will find port 3389 closed or filtered, eliminating scanning traffic completely.

---

Step 2: Installing and Running cloudflared as a Windows Service

Cloudflare Tunnels rely on cloudflared, a lightweight open-source connector developed in Go^[3].

1. Download the Connector Binary

Download the official 64-bit Windows release (cloudflared-windows-amd64.exe), place it into a dedicated administrative directory (e.g., C:\Cloudflared\), and rename it to cloudflared.exe.

2. Create the Tunnel in Cloudflare Zero Trust Dashboard

1. Navigate to Cloudflare Zero Trust Dashboard > Networks > Tunnels.
2. Click Create a tunnel, select Cloudflare Connector, and name your tunnel (e.g., Prod-Windows-RDP-Tunnel).
3. Select Windows (64-bit) as the operating system environment.
4. Copy the installation command containing your unique base64 tunnel token^[3]:

C:\Cloudflared\cloudflared.exe service install <YOUR_TUNNEL_TOKEN>

Execute this command in an elevated Command Prompt. The command registers cloudflared as an automatic Windows Service and begins streaming outbound connections over QUIC to the closest Cloudflare data center^[3].

Verify service registration:

Get-Service -Name cloudflared | Select-Object Name, Status, StartType

3. Route the Public Hostname to Local RDP

Under the Public Hostname configuration tab in the Cloudflare dashboard:

• Subdomain: rdp
• Domain: yourdomain.com (e.g., rdp.yourdomain.com)
• Service Type: RDP (or TCP)
• URL: localhost:3389 (or 127.0.0.1:3389)

Save the hostname. Cloudflare automatically generates the required CNAME DNS record pointing to your tunnel UUID.

---

Step 3: Configuring Zero Trust Access Policies & Multi-Factor Authentication

To ensure only authorized administrators can reach the tunnel endpoint, protect the hostname with Cloudflare Access^[4]:

1. In the Zero Trust dashboard, go to Access > Applications > Add an application.
2. Select Self-Hosted^[4].
3. Configure Application Settings:
   • Application Name: Windows Server Production RDP
   • Application Domain: rdp.yourdomain.com
   • Session Duration: 24 hours (or per enterprise security policy)
4. Add an Access Policy:
   • Policy Name: Authorized Systems Administrators
   • Action: Allow
   • Rules: Include Emails ending in @yourcompany.com or assign an authorized Google / Okta / GitHub group.
5. Enable Identity Providers: Configure Google OAuth, GitHub, or One-Time PIN (OTP) email verification.

Any unauthorized user attempting to connect to rdp.yourdomain.com will receive no raw TCP handshake and cannot reach the underlying Windows RDP listener^[2][4].

---

Step 4: Connecting from the Client Machine

Because standard Microsoft Remote Desktop Connection (mstsc.exe) does not natively speak Cloudflare Access HTTP headers, cloudflared is used on the client machine to act as a local proxy forwarder^[2].

Method A: Client-Side Proxy Listener (Recommended)

1. Download and install cloudflared on the client laptop (Windows, macOS, or Linux).
2. Execute the following command in PowerShell or terminal^[2]:

cloudflared access rdp --hostname rdp.yourdomain.com --url rdp://localhost:33899

3. Launch standard Windows Remote Desktop (mstsc.exe).
4. In the Computer field, enter:

   localhost:33899

5. Click Connect.
6. A browser window immediately pops up prompting the user to authenticate through your configured Identity Provider (e.g., Google Workspace MFA).
7. Once authenticated, Cloudflare issues a secure short-lived token, the local proxy authenticates the TCP stream, and the standard Windows login prompt appears seamlessly^[2].

Method B: Native WARP Client Routing

Alternatively, for managed corporate devices, administrators can deploy the Cloudflare WARP client. By enrolling user devices into the Zero Trust organization and configuring private IP routing (e.g., 10.0.10.5/32), users can connect directly to internal private IP addresses using standard mstsc.exe without running client-side proxy commands.

---

Step 5: Validating Security & Audit Telemetry

Verify that the perimeter is fully secured and monitor active administrative sessions:

1. Port Scan Verification:
   Run an external port scan against your server’s public IP from a remote testing machine:

   nmap -p 3389 -Pn <PUBLIC_SERVER_IP>

   The result will report filtered or closed, confirming that zero external attackers can reach port 3389.
2. Access Audit Logs:
   In the Cloudflare dashboard under Logs > Access, review real-time authentication logs, including user email, identity provider responses, client IP, geographic location, and device posture status^[4].
3. Windows Event Viewer:
   Inspect Microsoft-Windows-TerminalServices-LocalSessionManager/Operational to verify that all successful connections originate from 127.0.0.1 (the local tunnel endpoint), completely insulated from external network scanning.

---

High-Performance Domestic Hosting for Zero-Trust Workstations

For developers, algorithmic traders, and engineering teams in Pakistan, network latency is the single most critical factor in remote desktop responsiveness. Standard international VPNs and distant cloud regions introduce significant mouse lag and audio desynchronization.

By hosting your environment on Dedicated Servers in Pakistan, your RDP sessions benefit from direct peering through the Pakistan Internet Exchange (PKIX) and local Tier-1 telco providers. Combined with Cloudflare’s localized presence in Karachi and Islamabad, users achieve single-digit round-trip latency (sub-10ms), providing a true local-workstation experience with enterprise zero-trust security.

---

Sources & Official References

1. Microsoft Learn — Allow Remote Desktop Access from Outside Your PC's Network & Network Level Authentication. Official guidance on configuring Remote Desktop connections, enforcing Network Level Authentication (NLA), and managing firewall port requirements.
2. Cloudflare Developers — RDP Client-Side cloudflared Authentication Runbook. Authoritative engineering documentation for configuring non-HTTP RDP tunnels, `cloudflared access rdp` client listener commands, and browser-based edge authentication.
3. Cloudflare Developers — Running Cloudflare Tunnel as a Windows Service. Step-by-step documentation on installing the `cloudflared.exe` binary, service registration (`service install`), and outbound QUIC connector parameters on Microsoft Windows Server.
4. Cloudflare Developers — Self-Hosted Public Applications in Cloudflare Zero Trust. Official reference for defining Access application domains, multi-factor identity provider (IdP) integration, and session duration enforcement at Cloudflare's global edge.

---