RDP Freeze Over VPN: Input Still Works, So Test Transport

When the picture stops updating but the mouse still glides across the remote desktop, the obvious conclusion is that the VPN dropped. That conclusion is usually wrong. A frozen frame with working input means the session and its input channel are alive, which pushes the fault toward the graphics transport rather than toward routing or credentials. Two quick observations separate the three failures that users describe with the same word.

What the freeze is not telling you

Remote Desktop carries input and screen updates over TCP 3389, and current Windows clients can add a UDP transport for the graphics-heavy part of the stream. On a tunnel that fragments or drops larger datagrams, the reliable channel keeps carrying keystrokes while the graphics channel stalls. The result is the strange combination of a stuck picture and a responsive keyboard. It also explains why reconnecting sometimes cures the symptom for a minute and then brings it back.

A session that disconnects and reconnects is a different fault, and one that never opens at all is a third. Naming the shape first keeps you from testing the wrong layer.

Separate the three failures with two commands

Reachability is cheap to rule out. Test the RDP port from the client, then read the session state on the host.

Test-NetConnection rdp-host.example.com -Port 3389
query user /server:rdp-host

A failed TCP test means the session never opened, so treat it as a firewall, scope or service problem rather than a freeze. A successful test with an active session confirms the control channel exists, which is exactly the frozen-picture case. Run the host query from an account permitted to see sessions, because a permission error looks like an empty list. Record the session ID and state, since a disconnected session holding its ID is not the same as an active one.

Turn off the UDP transport and compare

If the display is the only thing that stalls, compare client transports one change at a time. The inbox client and the Store client do not share a stack, and the policy below removes UDP from the inbox client.

reg query "HKLM\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services\Client" /v fClientDisableUDP

A value of 1 means UDP is already off for that client, so a freeze that survives the setting is not a UDP-path problem. When the value is missing, enable the policy, reconnect, and repeat the exact action that froze before. Test the Store client as a separate step rather than combining both changes, or you will not know which one mattered. Keep the client version in your notes, because transport behaviour has shifted across Windows releases.

When one host freezes but the rest are fine

A single failing host on an otherwise healthy subnet points away from the tunnel. Check the path MTU and the remote display stack before touching VPN settings.

ping -f -l 1472 rdp-host.example.com

A reply proves the path carries a full-size packet without fragmentation at that size, while a failure with the do-not-fragment flag suggests the tunnel's MTU needs attention. If 1472 bytes pass and only that host freezes, look at its graphics driver and load instead of the network. A fast file copy to the same machine says something about throughput, not about the RDP graphics channel. Change one variable at a time and repeat the same on-screen action so the comparison means something.

If the session never opens at all, stop here, because that is reachability rather than a freeze. Otherwise keep the transport setting that changed the symptom and record it with the client version.