RDP stops after a VPN client install? It is the firewall

Minutes after a consumer VPN client finishes installing, the portal still says the VM is running, the public IP has not changed, and RDP times out. People usually assume the VM crashed or the network security group changed, and both are usually wrong. What changed is the Windows firewall profile the machine is in, and the RDP rule that used to match no longer does. The fix starts by getting a shell through a path that does not depend on RDP.

The VM is running; the rule stopped matching

Firewall rules in Windows carry a profile set, and a rule scoped to Private or Domain has no effect while the machine sits on the Public profile. VPN installers add adapters and routes, and several of them harden Public as a side effect. The listener remains bound to 3389 and the packets still arrive, but the profile mismatch discards them.

Power state and reachability are separate facts, and a running VM with a closed port looks exactly like a crashed one from outside.

Probe the port before editing anything. A connect attempt to 3389 that times out while a guest-agent command still returns output points at the host firewall. A port that answers while RDP still fails means the fault sits above the network layer, and this repair will not touch it. Note which of the two you saw, because the rest of the plan depends on it.

Two gates close independently

Fabric policy runs first: the network security group sees the packet before the guest does. That ordering makes a perfect NSG entry useless when the host drops the packet, and an open host rule useless when the fabric denies it. Treat them as separate gates and test each one on its own.

Read the NSG's effective rules in the portal or CLI, then compare them with the guest's own rules. Do not assume the last change you remember is the one that took effect.

A consumer client can also install a filter driver or a kill switch that blocks traffic below the Windows Firewall. If the firewall rules look correct and the port still fails, that layer is the next suspect.

Use the guest agent as your way back in

Two remote-execution features, Run Command and the Custom Script Extension, run inside the guest by way of the fabric agent. Neither needs RDP, so the firewall mistake does not affect them. Both return the script's output, which makes them a diagnostic channel as well as a repair channel.

Read the active profile and the RDP rule before changing either:

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

Re-enabling inbound rules on that profile is a temporary measure, not a destination. Use it to get a session, then close the gap properly:

Set-NetFirewallProfile -Name Public -AllowInboundRules True

That switch opens every inbound rule on the profile, not just RDP. Once you have a session, replace it with a scoped rule and restore the settings you actually want. If the agent is unavailable too, a serial console or a rebuilt disk is the fallback, which is the practical reason to keep the agent healthy.

Narrow the hole before you close the session

The temporary profile change is a door held open for every inbound rule on that profile. Replace it with a rule scoped to your source address and the RDP port, then confirm the profile is back to its intended state. Do this while you still have the session, because the next mistake may not be reversible remotely. Keep a second administrative path such as Bastion or a serial console during the change.

Confirm the result from your workstation with a port test, and from inside the guest with the rule list:

Test-NetConnection -ComputerName 203.0.113.25 -Port 3389
Get-NetFirewallRule -DisplayName "RDP from admin" | Get-NetFirewallPortFilter

Turn on firewall logging for the duration of the test. A single dropped-packet line that names 3389 and the active profile answers the question faster than another reboot.

Stop the next installer from doing it again

If that host has no reason to run the client, uninstall it. An installed client is a standing invitation for the next update to rewrite the profile again, and the next person will debug the same outage from the portal.

Snapshot the disk before you let anything rewrite network settings, and keep a second administrative path ready before you need it.

Record what the installer modified: adapters, routes, firewall profiles, filter drivers, and services. That record turns the next incident into a known pattern instead of a fresh investigation. When the VM needs a tunnel to exactly one service, put the client on your workstation or build a site-to-site link instead of installing a laptop product on the server. Consumer clients target laptops, and a server you administer remotely is not that.