Why RDP Freezes When the Remote Computer Connects to a VPN

You are inside the RDP window, the desktop is on screen, and you press Connect in the VPN client running on that remote machine. Seconds later the window freezes and then closes. The tunnel came up, which is exactly what the VPN log will report, and that is the least useful fact in the whole incident. The session died because the machine you were talking to changed the way it answers you, so walk the return path before you touch the tunnel.

Note the endpoint your session actually uses

The address typed into your RDP client is not necessarily the address the remote PC replies to. NAT, an RD Gateway, or a load balancer in front of the host can rewrite it, and the return path is defined by whatever source address the remote machine sees on the established connection. Getting that wrong sends you looking for a route that was never involved.

On the remote PC, before the VPN is connected, list the established sessions and read the peer address out of the table. Then write it down somewhere outside that machine, because you will not be able to read it after the session drops.

Get-NetTCPConnection -LocalPort 3389 -State Established |
  Select-Object LocalAddress, RemoteAddress, RemotePort

Treat that address as the thing that must stay reachable. If it is a private address on a management VLAN, the tunnel has to leave that path alone. If it is a public address, the reply has to leave through the same interface that carried the request in.

Read the route that answers that endpoint

Windows picks an interface per destination, and Find-NetRoute shows the decision it would make right now. Run it against the peer address before connecting, then again with the tunnel up, and compare the interface index and next hop in the two answers. A change of interface is the whole bug in one line of output.

Find-NetRoute -RemoteIPAddress 203.0.113.24
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
Get-VpnConnection -Name "Work VPN" | Select-Object SplitTunneling, Routes

A full-tunnel profile installs a default route through the tunnel, as the Windows VPN routing guide describes, so every reply now leaves through the VPN and depends on the far side routing back to your client. A split-tunnel profile is safer by default but not immune, because a specific route that covers the peer address can still win over the physical default route. Either way the question is identical: after the tunnel comes up, does the peer address still resolve to the interface that carried the session in?

If it does not, the fix belongs in the profile or in an explicit exception route approved by whoever owns the VPN policy. Editing the routing table by hand on a production host during an incident is how a temporary workaround becomes undocumented configuration.

Watch the firewall profile change

A new interface is classified when it appears, and the classification decides which firewall profile its traffic is judged against. A tunnel adapter that lands in the Public category can silently stop inbound RDP even though the routing table looks perfect. This is the second failure mode, and it produces a different symptom: the route is right, the packets arrive, and the host refuses the connection.

Get-NetConnectionProfile
Get-NetFirewallProfile | Select-Object Name, Enabled
Get-NetFirewallRule -DisplayGroup "Remote Desktop" | Select-Object Name, Enabled, Profile

Compare the profile attached to the tunnel interface with the profiles the Remote Desktop rules are scoped to. A rule enabled only for Domain and Private does nothing for an interface classified Public, and no amount of route correction changes that. Some VPN clients also restrict local subnet access by design, which produces the same shape of failure from a different control.

Test the transition from somewhere recoverable

Do the whole sequence from an out-of-band console or a second management path, in this order: confirm the existing session, connect the VPN, open a fresh session, then disconnect the VPN and open another. Each step tests a different transition, and the first one that fails tells you which control is responsible.

Schedule the rollback before you start, for example a scheduled task that runs rasdial "Work VPN" /disconnect after a set interval. That turns a lost session into a five-minute interruption instead of a site visit, and it is the cheapest insurance in the whole procedure.

Get back in when the session is already gone

If the host is already unreachable, stop trying new RDP connections from the same client and use the recovery channel the environment already has: an RD Gateway, a hypervisor console, or an out-of-band management interface. Ask the person with console access to run the same Find-NetRoute and Get-NetConnectionProfile commands so the evidence survives the recovery.

Then decide the permanent arrangement rather than the quickest one. Either the management path is explicitly preserved by the VPN profile, or management moves to a channel that does not depend on the host's default route. Both are supportable; a host route with a guessed gateway is not. Write down which one you chose, and record the peer address that had to survive.