Adding an RDP allow rule does not narrow your VPN access

The plan sounds reasonable: leave the existing Remote Desktop allowance alone and add a small one for the single VPN client that should have access. Windows Firewall does not work that way. Rules are not an ordered list where the most specific entry wins, and a narrow allow beside a broad allow changes nothing, because the broad one still admits everybody it already admitted. Narrowing the service means editing the permit that is already doing the work.

The rule you add is not the rule that matters

Windows Firewall evaluates all applicable inbound rules across the policy stores that apply to the machine, then decides whether any allow matches and whether any block overrides it. Adding a rule adds a permit; it does not remove or qualify the permits already there.

So the question is never what you added. It is what the effective policy contains after local policy, domain policy and the profile defaults are merged. A workstation with one local rule is easy to reason about; a server joined to a domain is not.

That is also why an administrator can make a correct-looking change, test it from the wrong machine, and conclude it worked. The excluded source was never tested. A test that only proves success proves less than half of what the change was for.

Find out which address the server sees

Before scoping anything, observe one permitted session at the Windows host and record the source address the server reports. This is not always the address the client believes it has.

If the VPN gateway preserves client addresses, the server sees the tunnel address of the client, and an address-scoped rule is meaningful. If the gateway translates, every client arrives as the gateway address, and scoping to that address grants access to every client behind it. The rule is then precise about the wrong thing.

Those two designs need different answers. The first can be expressed in a firewall rule; the second has to be enforced where identity still exists, which is the VPN itself or an authenticated gateway in front of the service.

A firewall filter cannot recover an identity that network translation discarded, no matter how carefully the address is typed.

Change the owner of the effective rule

Inspect the effective inbound policy and find every rule that currently admits RDP traffic, including rules whose display name never mentions port 3389. Service-scoped and application-scoped rules count too, and so does the UDP transport some RDP deployments enable.

Then edit the existing rules through whichever store owns them. A local edit to a rule that domain policy also defines may be merged, ignored or overwritten, and which of those happens is worth knowing before you rely on it.

These commands find the active rules, show the address filter attached to one, and preview a scope change:

Get-NetFirewallRule -PolicyStore ActiveStore -Direction Inbound | Where-Object DisplayName -match RDP
Get-NetFirewallAddressFilter -AssociatedNetFirewallRule (Get-NetFirewallRule -Name Reviewed-RDP-TCP)
Set-NetFirewallRule -Name Reviewed-RDP-TCP -RemoteAddress 10.63.4.17 -WhatIf

The rule names here are placeholders for what the review found, and the preview flag exists so a typo in an address does not lock you out of the server you are editing.

Block-then-allow is a different model

The habit from other firewalls is to write a broad block and then a narrow allow above it. On Windows an explicit block generally wins over an allow, so that ordering produces a service nobody can reach rather than an exception for one client. The result is an outage that looks like a broken RDP service. It is really a precedence mistake, and the fix is to remove the block rather than to add another permit.

Keep the default inbound block behaviour on the active profiles and narrow the specific allows instead. That leaves the machine with one understandable posture rather than two contradictory rules whose interaction depends on precedence details.

Prove it with a second source

Test from the allowed client and from a source that should now fail. A single successful connection proves only that the allowed path works; it says nothing about the exclusion you just made.

Repeat the test over IPv6 if the server has it enabled, because an IPv4-only intention can coexist with a wide IPv6 allowance that nobody looked at.

Finally, keep authentication separate from reachability. Network Level Authentication, account rights and logon restrictions still decide who may use the session, and the firewall only decides who may ask. Removing a device later should remove both its VPN enrollment and this network permission, or the address you scoped will eventually belong to somebody else.