IPv6 Privacy Addresses or an RDP Allowlist: Pick the Trade-off

Remote desktop access worked for a month, and then the allowlist stopped matching for no reason anyone could see. The host had not moved and nothing in the firewall had been edited. Windows keeps forming IPv6 temporary addresses with random interface identifiers and retiring them, so the source address the server sees on any given day may be one nobody wrote into the rule. Disabling that behaviour fixes the match and converts the host into a long-lived identifier at the same time. Weigh the alternatives before you accept the second half.

Why the rule stopped matching

RFC 4941 describes temporary addresses: the host creates additional addresses with randomised identifiers and deprecates them, which keeps an observer from correlating one host across visits. Windows implements that behaviour, so yesterday's source address is not necessarily today's. The predictable address still exists on the interface; it is simply not the one an outbound connection prefers.

That is why the failure looks intermittent rather than total. The rule matches for a while after the address is created, stops matching once it is retired, and starts matching again after somebody edits it. Monitoring grouped by source address and licence checks keyed on a host address break on the same schedule. A rule that works right after it is edited and fails three weeks later is usually this, not a firewall reload.

Option one: one stable address, less privacy

The usual repair switches off both rotating mechanisms on the host: netsh interface ipv6 set privacy state=disabled store=persistent and netsh interface ipv6 set global randomizeidentifiers=disabled store=persistent. Add store=active if you want the change to take effect without waiting for a restart, and accept that you have now made the identifier predictable across networks.

That predictability is exactly what the extensions were built to prevent. An address that follows the host from café to office to home is a convenient filter key and an equally convenient tracking key, and the second property outlives the ticket that asked for the first.

Option two: allow a prefix or a name

Allowing the /64 rather than the full address keeps rotation intact and matches a weaker but often honest claim: this machine is on my home network. It stops being adequate the moment that prefix contains hosts you would not admit, which on a consumer connection is usually a smaller set than people assume. A name published through dynamic DNS is easier to operate, because the record follows the host and the policy reads as an identity rather than as a range that grows whenever a device is added.

Both options need a resolver the server can trust and a name that is not trivially spoofable, so treat them as a policy decision about identity rather than as a cosmetic change to the rule. Write down which resolver answers that name, because the rule is only as trustworthy as the record behind it.

Option three: let the tunnel assign the address

If the connection crosses a VPN you control, the server can hand out the address from its own pool, and the allowlist then references a value the server chooses rather than one the client prefers. That works well for managed clients and badly for anything the client can override, so verify which side actually wins on your deployment.

Moving the decision off the address entirely, to a client certificate or an authenticated gateway, is the option that scales, because it stops depending on a value that the operating system is entitled to change.

Choose with the tracking cost in view

Write the four options against the actual requirement, and pick one rather than combining them. If you disable privacy anyway, scope it to the host that needs it, document the reason beside the rule, and consider stable-privacy addressing from RFC 7217 where the platform supports it, since it keeps a per-prefix identifier without exposing the hardware-derived one. Re-enable the extensions when the allowlist is replaced.

Record the change next to the rule it supports. Without that note the next administrator finds a host with privacy extensions off and no explanation, and switches them back on during a cleanup.