Secure RDP to a domain controller, reachable only over VPN

The listener does not come up until you reboot, and the service refuses to restart by hand. Then a firewall rule that only lets the VPN through.

A domain controller is the machine you least want reachable and most need to reach. This is how it ended up: RDP enabled, but answering only to traffic arriving through the VPN — with two surprises along the way, one of which looks like a broken service.

Enabling it, and the reboot nobody warns you about

Server Manager → Local Server → Remote Desktop → Enable, leaving NLA on.

Then it does not work.

Restart-Computer -Force

After the reboot, verify on the server itself:

netstat -ano | findstr ":3389"
# atteso: 0.0.0.0:3389 ... LISTENING

Test-NetConnection -ComputerName 127.0.0.1 -Port 3389
# atteso: TcpTestSucceeded : True

Reaching it without exposing it

The domain controller is not a VPN node itself. It is reached through a subnet router: another machine on the same network that advertises the subnet to the VPN.

On the client, routes have to be accepted explicitly — this is off by default, and it is the usual reason a subnet router “does not work”:

tailscale set --accept-routes=true

Then mstsc to the server’s private address, signing in as DOMAIN\Administrator. Under Local Resources → More → Drives, share a drive: file transfer through the RDP session is considerably less trouble than arranging a share into a management network.

The restriction that makes it VPN-only

At this point RDP works from anywhere on the local network, which is more than was intended. The goal is: reachable through the VPN, and not otherwise.

The useful discovery is what the traffic looks like when it arrives.

Check

Traffic through a subnet router arrives SNATed to the router’s own address. From the domain controller’s point of view every VPN connection appears to come from one machine — the subnet router — regardless of which device actually initiated it.

Verify rather than assume, with a session open:

Get-NetTCPConnection -LocalPort 3389 -State Established

The remote address shown is the subnet router’s. That single address is what the firewall rule can be built on.

So the restriction is one line:

Get-NetFirewallRule -DisplayGroup "Remote Desktop" |
    Set-NetFirewallRule -RemoteAddress 192.168.50.10

Result: RDP to the domain controller is reachable only through the VPN, and not from other devices on the local network.

What this protects against, and what it does not

Worth being precise, because it is easy to overstate.

It does protect against anything on the local network: an IoT device, a guest laptop, a compromised workstation on another VLAN. None of them can reach 3389 on the domain controller any more, because their source address is not the permitted one.

Two things worth keeping

A protected service that will not restart is not a fault. TermService refusing to stop looks like something is broken. It is by design, and the reboot is the supported path — worth knowing before spending time trying to force it.

Find out how the traffic actually arrives before writing a rule about it. The SNAT behaviour of the subnet router was the difference between a rule that works and a rule that would have quietly blocked the access it was meant to preserve. One command, with a live session open, answered it.