Firewall Profiles: Public vs Domain After a Windows VPS Reboot

TL;DR: After a reboot, Windows can reclassify the NIC as Public and apply a stricter firewall profile—silently blocking RDP, SQL, or custom ports that worked yesterday. Confirm the active profile, set the network category deliberately, and align provider security groups with guest rules on your Windows VPS.

Why the same ports “disappear” overnight

Windows Firewall is not one flat allowlist. It evaluates Domain, Private, and Public profiles, each with different default outbound and inbound posture. On physical office PCs the Domain profile appears when Active Directory detects a domain controller. On a rented VPS you are usually workgroup-only, so Windows falls back to Private or Public based on how the network stack remembers the adapter.

Provider maintenance, snapshot restores, and cloud-init style NIC renames can wipe that memory. The guest boots, sees an “unidentified” network, and chooses Public. Your carefully opened inbound rules may be scoped only to Private. Result: the panel security group still allows TCP 3389, yet Windows drops the packets before the RDP service answers.

Operators often blame the host firewall first. Spend two minutes inside the guest before opening a ticket—profile mismatches create the same symptoms as a closed cloud ACL.

How to read the active profile quickly

Open an elevated PowerShell session after you regain console or RDP access:

• Get-NetConnectionProfile — note Name, InterfaceAlias, and NetworkCategory.
• Get-NetFirewallProfile — confirm which profiles are enabled and whether inbound is Block.
• wf.msc — visual check if a rule’s Profile column excludes Public.

If NetworkCategory is Public and your RDP allow rule is Private-only, you have the smoking gun. Do not disable the entire firewall to “test.” That habit survives into production and invites scanners. Change the category or widen the specific rule’s profile scope with intent.

Console recovery when RDP is already locked out

Use the provider’s VNC/serial console, not hope. From console, set the category:

Set-NetConnectionProfile -InterfaceAlias "Ethernet" -NetworkCategory Private

Replace the alias with whatever Get-NetAdapter shows. Some images use “Ethernet 2” after a hardware UUID change. Persist a note in your runbook with the exact alias for that instance.

Domain profile myths on solo VPS boxes

Seeing “Domain” on a non-joined VPS is rare and usually means leftover GPO tooling or a misapplied image. Do not chase Domain profile settings unless the machine truly joins your AD. For typical RDP jump hosts and IIS singles, Private is the sane category when the NIC is on a trusted VPC, and Public is appropriate only when the adapter faces a hostile shared network you refuse to trust.

If you later domain-join the guest, revisit firewall baselines—Domain rules from GPO can override local MMC edits. Document whether local or domain policy wins before the next reboot surprise.

Scope rules the way you scope cloud ACLs

Mirror the discipline you already use on the provider panel:

• Prefer allow rules limited to admin source IPs when the product supports it.
• Duplicate critical allows across Private and Public only when you knowingly accept Public after reboots.
• Keep ephemeral lab ports on Private-only so a Public flip fails closed for experiments.

Export your firewall policy with netsh advfirewall export after a known-good state. Restoring that file beats rebuilding twenty rules after a bad image clone.

Provider security groups are not a substitute

Cloud ACLs stop packets before they reach the guest. Guest profiles stop packets after they arrive. You need both layers coherent. When you open 443 on the panel but IIS still fails from the internet, check Windows profile and binding address. When Windows is Private-open but the panel still denies your home IP, fix the panel—not the guest.

After any panel change, retest from a phone hotspot so you are not fooled by a corporate egress that was already allowlisted. Record both the guest NetworkCategory and the panel rule IDs in the change ticket.

Reboot drills that catch profile flips early

Schedule a controlled reboot after first provisioning and after major NIC or Windows Update sessions. Immediately run Get-NetConnectionProfile and attempt RDP from a second network. If Public returns, either force Private via a startup script you maintain, or widen the RDP rule profiles and accept the trade-off.

Startup scripts should be idempotent and logged. Silent Set-NetConnectionProfile failures (wrong alias) are worse than no script at all because they create false confidence.

Keeping IIS and SQL reachable without flattening security

Web and database workloads often add their own inbound rules during installers. Those rules inherit whatever profile set the installer used that day. After a Public flip, HTTP may die while RDP still works—or the reverse. Audit installer-created rules quarterly; consolidate into named rule groups with explicit profile scopes.

For SQL over the internet (generally discouraged), require Private + VPN or SSH tunnel patterns rather than Public allow-anywhere. Profile hygiene will not save a wide-open 1433.

Stable NIC naming as the quiet dependency

Profile fixes fail when InterfaceAlias changes after every restore. Prefer identifying adapters by InterfaceIndex or MacAddress in scripts. Pin provider “network config” so hot-plug events do not spawn Ethernet 4. A stable alias makes Private enforcement boring—which is exactly what you want on a long-lived windows-vps.org guest.

Treat firewall profile checks as part of the same post-reboot smoke test as time sync and disk space. When Public versus Private stops being a mystery, overnight “port disappeared” tickets mostly disappear with it.