
There are two usual ways to Remote Desktop into a machine that isn't on your LAN, and both are bad in their own way.

The first is to **forward port 3389** on the router and connect to the public IP. It works, and it's also how a huge share of ransomware gets in; an exposed RDP port is a doormat that every scanner on the internet is already knocking on. The second is to **stand up a VPN** first, which is more work, more to maintain, and usually gives the remote device far more of your network than "I just want to reach that one PC."

Reach RDP is a third way: your **existing** Remote Desktop client connects to the remote machine over an **identity-gated tunnel**, with **nothing exposed** and **nothing forwarded**.

## What it looks like

The remote machine turns on "Share this PC," which advertises its RDP service (port 3389) to your TYO ID, or to a teammate you've explicitly shared it with. From the other end you pick that machine and Reach does two things: it stands up a **local forward** (a listener on `127.0.0.1`) and launches your normal RDP client at it. To mstsc / Microsoft Remote Desktop / Remmina, it looks exactly like connecting to a machine on your own desk. The bytes, meanwhile, are travelling through Reach's tunnel to a box that could be behind NAT, behind CGNAT, or in another country entirely.

No inbound firewall rule. No public 3389. No static IP. The remote machine makes an **outbound** control connection to Reach and waits; your connection is matched to it by **identity**, not by address.

## How the bytes travel

Same substrate as the rest of Reach. If your device and the target are on the **same subnet**, the connection goes **peer-to-peer, directly**, and the gateway never sees your pixels. Otherwise it rides the **gateway relay**. Either way the RDP stream is tunnelled raw, with a couple of deliberate tunings (`TCP_NODELAY` and interactive PDUs flushed immediately) because the thing that makes tunnelled RDP feel awful is buffering keystrokes and mouse movement, and we don't.

## The security posture, and the sharp edges we filed down

RDP is fiddly, and getting it to tunnel *cleanly* took solving some genuinely annoying failure modes. A few worth naming, because they're the difference between "works" and "works reliably":

- **NLA stays on.** The tunnel doesn't weaken authentication: CredSSP / Network Level Authentication is preserved (`authentication level:i:2`). Reach moves bytes; it doesn't stand between you and the server's auth.
- **A forced, fresh credential prompt.** Because every Reach target shares `127.0.0.1` on your machine, mstsc would happily reuse a credential it cached against that address from a *different* box: connect to a domain-joined machine, then a workgroup one, and it tries Kerberos against a KDC it can't reach and dies before you even see a prompt (`0x80090311`). Reach's generated `.rdp` forces the prompt so you enter *that* machine's own credentials.
- **An old-server quirk (`HYBRID_EX`).** Some older RDP servers reset the connection if the client advertises `PROTOCOL_HYBRID_EX`; Reach can strip it from the X.224 request for exactly those hosts (off by default, because modern Windows needs it kept).
- **Secure mode.** For locked-down access you can strip the clipboard, drive and USB redirection virtual channels, so a session is view-and-control only with no data bridge back to the host.

## Multi-monitor, and other client features

Because Reach tunnels the raw RDP stream, **multi-monitor works out of the box**. Reach's generated `.rdp` now sets `use multiple monitors:i:1`, so a full-screen session spans all your displays as if the box were on your desk; it's a no-op on a single monitor, and windowed mode still behaves normally. Same story for other RDP features: they're between your client and the host, and Reach is transparent to them.

## Coming from TeamViewer or AnyDesk?

If you reach your machines with TeamViewer, AnyDesk or Dualmon today, Reach is the same "get to any of my boxes from anywhere" capability with a very different design underneath. Those tools re-encode the remote screen with a proprietary codec and relay it through the vendor's cloud. Reach instead tunnels each OS's **native** remote protocol end-to-end: **RDP** to Windows, **VNC** to a Mac (its built-in Screen Sharing) or Linux, **SSH** for a shell. So you get native fidelity (real multi-monitor, proper keyboard/printer/USB redirection on RDP) rather than a screen video stream, and the whole session is identity-gated with nothing exposed. There's no anonymous nine-digit session code to read out to whoever's on the phone, which is precisely the mechanism those tools get abused through. The trade: Reach reaches machines you **own or have been granted**, not a stranger's PC on a one-off support call.

And RDP isn't the only gear. When you don't need the full graphical desktop, and just want to get back to what you were doing, **Reach Sessions** is the lighter, faster way in: a persistent working session you can detach from and reattach to from any device, picking up exactly where you left off. Full desktop when you need it, a light resumable session when you don't.

## What it isn't

- **It's a transport, not an RDP server.** You still need a remote machine actually running Remote Desktop (a Pro/Enterprise/Server edition; Windows Home doesn't host RDP, and multimon needs a non-Home edition too). That's the *Windows* door specifically; to reach a **Mac** or **Linux** box you use Reach's **VNC/SSH** path instead, so non-Windows targets aren't left out.
- **Secure mode is a trade.** Stripping clipboard/drive/USB is the point when you want it, and an annoyance when you forget it's on; it's per-forward, so you choose.

The headline, though, is the one that matters for anyone who's ever port-forwarded 3389 and then watched the failed-login counter climb: you can have Remote Desktop to any of your machines, from anywhere, using the client you already use, and leave **nothing** listening on the public internet.

*Reach RDP is part of TYO Reach. Already a Reach user? It's in the desktop app under "Share this PC" and Remote Machines. New to Reach? [Start here](https://reach.tyo.com.au), or go straight to the [download](https://reach.tyo.com.au/download).*


882545917a417cb9ab0135129980d145ac59dbdeb529e803ab87a35878e82073

How TYO Reach carries RDP over an identity-gated tunnel to a remote Windows machine with no port-forwarding and no exposed 3389, P2P-or-relay transport, NLA preserved, a forced fresh credential prompt, an optional secure mode that strips clipboard/drive/USB, and transparent multi-monitor passthrough.

Remote Desktop usually means either exposing port 3389 to the internet (the number-one ransomware doormat) or standing up a VPN. Reach RDP does neither. It tunnels your existing Remote Desktop client to the machine over an identity-gated path, so nothing is exposed and nothing is forwarded.

Reach RDP: remote desktop without opening a hole in your network


{/* banner prompt: A vivid infographic-style scene where a stream of glowing data blocks flows through a semi-transparent proxy filter that visibly plucks out a single red block, labelled "0x08", causing a connection icon downstream to display a red error symbol "0x609". Clean light-gray background, sharp isometric perspective, muted blue-and-red palette, technical but clear. */}

RDP error 0x609, "An authentication error has occurred," is a CredSSP failure. The standard advice is to check your NLA settings, patch your CredSSP version, or relax the encryption level. None of it helped us, because the error only appeared when connecting *through a proxy*. Direct connections to the same server worked perfectly every time.

That asymmetry is the only clue you need. If direct works and proxied doesn't, the proxy is transforming something it shouldn't be.

## The setup

We were relaying RDP over a WebSocket tunnel: client connects to a local port, a relay forwards the raw TCP stream through a WebSocket connection to a gateway, gateway connects onward to the Windows machine. A standard CONNECT-style proxy, just over WebSocket instead of a raw TCP pipe.

The first phase of an RDP connection (X.224 → CredSSP → MCS → RDP) is negotiated in the clear before any screen data flows. Our relay passes bytes through untouched, so in theory the server should see exactly the same handshake whether or not a proxy is in the middle.

In theory.

## What 0x609 actually tells you

The Windows error 0x609 maps to `STATUS_LOGON_FAILURE` inside the CredSSP layer, but that description is misleading. It doesn't necessarily mean the credentials are wrong. It can also mean the CredSSP negotiation *completed* but the session couldn't be established afterwards; the error surfaces at the CredSSP layer because that's where the TLS channel lives, and whatever went wrong downstream comes back through it.

The useless nature of this error code is part of what makes 0x609 hard to debug. You're essentially told "something authentication-related failed" without any pointer to where in the multi-phase handshake the failure occurred.

## Reading the X.224 handshake

RDP starts with an X.224 Connection Request (CR) from the client. Buried inside the TPKT/X.224 framing is a `requestedProtocols` field: a bitmask that advertises which security layers the client supports:

- `0x01`: SSL/TLS
- `0x02`: NLA (CredSSP over NTLM/Kerberos), also called HYBRID
- `0x08`: HYBRID_EX (an extension to NLA used by modern Windows)

Modern `mstsc` sends `0x0b`, with all three bits set. The server responds with an X.224 Connection Confirm (CC) that includes a `selectedProtocol` field indicating which mode it chose.

Here is where we found the divergence.

**Direct connection:** the CC came back with `selectedProtocol = 0x08` (HYBRID_EX).

**Through the proxy:** the CC came back with `selectedProtocol = 0x02` (HYBRID, plain NLA).

Same client. Same server. Different `selectedProtocol`. The proxy was changing something in the CR before it reached the server.

## The hidden transformation

The proxy had a small normalisation function applied to the first TCP frame on each new connection. Its purpose was compatibility: some older Windows environments support NLA but reject HYBRID_EX outright, returning an immediate RST. So the function detected the X.224 CR structure, read the `requestedProtocols` field, and cleared the `0x08` bit before forwarding.

The intent was conservative: strip the extended mode, keep plain NLA, everything still authenticates. It worked on the servers we originally tested it against.

What we hadn't accounted for: some Windows Server versions advertise both HYBRID and HYBRID_EX, but internally require the HYBRID_EX flow to complete a session correctly. When forced into HYBRID mode by the altered CR, they complete CredSSP (all five steps of the NTLM exchange succeed, credentials are verified) and then the MCS Connect-Initial fails. The session can't start.

The mechanism: HYBRID_EX adds a step that HYBRID omits. After the CredSSP exchange, the server sends an Early User Authorization Result PDU before the MCS layer begins. This PDU is part of the HYBRID_EX contract. When the server is put into HYBRID mode (because `0x08` was stripped from the CR), it doesn't send this PDU, but if the server's internal session setup expects it, or if the subsequent MCS framing depends on state that only HYBRID_EX establishes, the session fails. From the client's side it arrives as a 0x609.

In pseudo-code, what was happening:

```
# CR goes out with 0x0b (SSL | NLA | HYBRID_EX)
# proxy strips 0x08 → 0x03 (SSL | NLA)
# server selects HYBRID (0x02) — the highest it can given the offer
# CredSSP runs normally and succeeds
# server tries to start MCS in HYBRID_EX mode internally
# HYBRID_EX Early User Authorization PDU never arrives
# MCS Connect-Initial fails
# error surfaces as 0x609 on the CredSSP channel
```

## The fix

Remove the stripping entirely. Pass `requestedProtocols` through unchanged.

The original compatibility concern, older servers rejecting HYBRID_EX, turned out to be unwarranted in practice. Modern `mstsc` has been sending HYBRID_EX for years and servers handle it gracefully: if they don't support it they simply select a lower mode in the CC. The server's CC is the right place for that negotiation to happen, not a proxy in the middle.

## What to check if you hit this

If you're seeing 0x609 only through a proxy and direct connections work:

1. **Capture both sides of the relay.** You want the raw bytes the server sees, not the bytes the client sent. Log the first frame in each direction.

2. **Find the X.224 CC and read `selectedProtocol`.** It's a 4-byte little-endian value a few bytes into the CC. If it differs between direct and proxied connections, the proxy is rewriting the CR.

3. **Check for any transformation applied to the first message.** Header parsers, encoding normalizers, protocol fixups: anything that touches the first frame of a new TCP connection is a candidate.

4. **Compare `requestedProtocols` in the CR.** If the proxy is changing the bitmask, restore it to pass through verbatim and retest.

The broader principle: a byte-stream proxy should be transparent. Any transformation that modifies the protocol negotiation, even a seemingly harmless bit-clear, can break assumptions downstream that neither the proxy nor its author can fully anticipate.

The server, not the proxy, decides which protocol variant to use. Let it.


b8ef18cc559c1fe2bdc93e4b58a8d9b7eeeefcd789d308818e0d0ace1cfbb831

How we debugged RDP error 0x609 appearing only through a WebSocket proxy, and why stripping the HYBRID_EX bit from the protocol negotiation breaks the entire session.

A CredSSP 0x609 error appearing only through a proxy but not on direct connections, traced to a single HYBRID_EX bit being silently stripped from the RDP X.224 handshake.

Debugging RDP 0x609: The Protocol Bit a Proxy Should Never Touch


{/* banner prompt: Of course! Here are three creative and engaging prompts for a banner image, each with a different artistic direction but all reflecting the core theme of the blog post.

---

### Prompt 1: The Beacon in the Void

This prompt uses a dramatic, cinematic approach to visualize the problem and solution as a source of light in darkness.

**Prompt:**
```
A cinematic, photorealistic image of a vast, dark, digital abyss representing a system failure. In the center, a single computer monitor floats, its screen pitch black except for the faintly glowing, ominous text "Please Wait...". From the top right corner, a powerful, clean beam of light, symbolizing a Windows update, descends and strikes the monitor. Where the light hits, the black screen begins to dissolve, revealing a vibrant, fully-loaded Windows desktop underneath. The light is composed of tiny, flowing data particles and the iconic circular update arrows. Moody, dramatic lighting, deep shadows, and a strong contrast between the dark void and the bright, hopeful light. --ar 16:9
```
**Why it works:** This prompt creates a powerful metaphor. The "black screen" is an empty void, and the "Windows Update" is a literal beacon of hope and functionality, cutting through the darkness to restore the system. It's visually striking and tells the story of the blog post in a single image.

---

### Prompt 2: The Digital Locksmith

This prompt takes a more conceptual, cyberpunk-inspired approach, framing the problem as a lock and the solution as the key.

**Prompt:**
```
A sleek, futuristic digital art piece. An IT professional is seen from behind, facing a massive, impenetrable digital wall that glows with a faint grid pattern. The wall has a single line of text embedded in it: "Please Wait". In the professional's hand is a glowing, holographic key forged from the Windows logo and circuitry patterns. They are about to insert this "update key" into a barely visible keyhole on the wall, causing cracks of bright blue light to emanate from the insertion point, ready to shatter the barrier and reveal the bright, working remote desktop behind it. Cyberpunk aesthetic with neon blues, blacks, and whites. --ar 16:9
```
**Why it works:** This prompt personifies the solution. The update isn't just a process; it's the "key" that the IT professional uses to unlock the problem. It highlights the user's frustration (the impenetrable wall) and the simple, elegant power of the solution (the key).

---

### Prompt 3: The System Corruption and Repair

This prompt visualizes the issue from a high-tech, schematic point of view, perfect for a more technical audience.

**Prompt:**
```
A high-tech, holographic schematic of a computer's system architecture, rendered in glowing blue and green lines against a dark background. A critical section labeled "RDP Service" is shown as dark, corrupted, and glitching, with a red "Please Wait" error message flickering nearby. From a main system node labeled "Windows Update Core," a clean, flowing stream of pristine data particles travels along the circuits to the corrupted RDP section. As the data arrives, it purges the corruption, turning the dark, glitching lines back to a healthy, vibrant blue, fixing the error in real-time. Style of an advanced UI display, sharp focus, depth of field. --ar 16:9
```
**Why it works:** This prompt appeals directly to a technical understanding of the problem. It visualizes the "pending update" as a form of system corruption or inconsistency that the update process actively "repairs." It’s a clean, modern, and intelligent way to represent the blog post's main idea. */}

If you've ever tried to connect to a Windows machine via RDP only to be greeted by an endless black screen displaying "Please Wait," you know how frustrating this can be. The good news? It could be an easy fix.

![](https://storage.googleapis.com/www-tyolab-com-blog-assets/images/blog/2026/02/rdp-please-wait-black-screen-a-simple-fix/please-wait.png)

In my case the target Windows machine has pending system updates that require installation or a restart to complete. Windows Update can interfere with the RDP service's ability to properly initialize the desktop environment, leaving users stranded at the "Please Wait" screen.

## The Simple Solution: Windows Updates

No matter how much we don't want to, but we have to: **update Windows**.

### Step-by-Step Fix

#### Option 1: Physical or Local Access

If you have physical access to the machine:

1. **Log in locally** to the Windows machine experiencing the RDP issue
2. **Check for Windows Updates**:
   - Press `Windows + I` to open Settings
   - Navigate to "Update & Security"
   - Click "Check for updates"
3. **Install all available updates**
4. **Restart the machine** when prompted
5. **Test RDP connection** after the restart completes

#### Option 2: Command Line Approach

If you have limited access but can run commands:

```shell
# Check for updates using PowerShell
Get-WindowsUpdate

# Install updates (requires PSWindowsUpdate module)
Install-WindowsUpdate -AcceptAll -AutoReboot

# Alternative: Use Windows Update command line
UsoClient StartScan
UsoClient StartDownload
UsoClient StartInstall
```

#### Option 3: Group Policy Method

For domain environments:

```shell
# Force Group Policy update
gpupdate /force

# Trigger Windows Update check
wuauclt /detectnow /updatenow
```

### Verification Steps

After applying updates and restarting:

1. **Test RDP connectivity**:
   ```shell
   # Test RDP port connectivity
   telnet target-machine-ip 3389
   ```

2. **Check RDP service status**:
   ```powershell
   # Verify Remote Desktop Services are running
   Get-Service -Name "TermService"
   Get-Service -Name "UmRdpService"
   ```

3. **Verify Windows Update status**:
   ```powershell
   # Check for pending updates
   Get-WindowsUpdate
   
   # Check update history
   Get-WUHistory | Select-Object Date, Title, Result
   ```



ecffff53591c09630c07f788ef84776284aa661e70b9677eb3926f6a94b51868

Struggling with RDP showing a black 'Please Wait' screen? Learn how pending Windows updates cause this issue and get the simple fix.

Fix RDP black screen with 'Please Wait' message by updating Windows - a simple solution that works.

Tag: Rdp

Tag: Rdp

Reach RDP: remote desktop without opening a hole in your network

Debugging RDP 0x609: The Protocol Bit a Proxy Should Never Touch

RDP 'Please Wait' Black Screen? A Simple Fix