Windows Defender Firewall on Windows Server: Rules, Profiles, and Inbound Traffic Control

Every Windows Server VPS ships with Windows Defender Firewall enabled, yet most setup guides treat it as an afterthought. Understanding three concepts — profiles, rules, and the default-deny inbound model — lets you lock down a server without breaking RDP, IIS, or SQL Server. This guide walks through how the firewall thinks, then gives you the exact commands for the scenarios that matter on a VPS.

How profiles work

The firewall applies three profiles — Domain, Private, and Public — and every network connection is assigned exactly one of them. On a VPS, the internet-facing interface is almost always classified as the Public profile, so rules you create for Private or Domain simply never apply. The practical consequence: when a rule “does not work,” the first thing to check is which profile the rule is bound to and which profile the network is using (Get-NetConnectionProfile).

The default-deny inbound model

Windows Defender Firewall blocks unsolicited inbound traffic by default and allows all outbound traffic by default. That means you do not secure a server by adding block rules; you secure it by adding allow rules only for the services you intentionally expose, and by keeping everything else denied. Most VPS hardening is therefore a matter of auditing the built-in allow rules (Remote Desktop, File and Printer Sharing, IIS) and disabling or scoping the ones you do not need.

Common VPS scenarios

Scope RDP to your IP range instead of leaving it open to the world — this is the single highest-value rule on any Windows VPS:

# Allow RDP only from your office / home CIDR
New-NetFirewallRule -DisplayName "RDP from trusted IPs" -RemoteAddress 203.0.113.0/24 -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Allow

Then disable the built-in, wide-open Remote Desktop rule so the scoped rule is the only path in:

Disable-NetFirewallRule -DisplayName "Remote Desktop (TCP-In)"

For a web server, enable only the IIS HTTP/HTTPS rules and leave the rest denied:

Enable-NetFirewallRule -DisplayName "World Wide Web Services (HTTP Traffic-In)"
Enable-NetFirewallRule -DisplayName "World Wide Web Services (HTTPS Traffic-In)"

Built-in rules worth auditing

On a fresh Windows Server image, a handful of built-in inbound rules are enabled by default. Audit each one against what the box actually needs to do:

• Remote Desktop (TCP-In): scope it to trusted IPs or disable it; RDP should never be open to the whole internet.
• File and Printer Sharing (SMB-In): disable on a public interface; port 445 is a favorite target for scanners.
• World Wide Web Services (HTTP/HTTPS): enable only if the box runs IIS and you have configured bindings.
• ICMPv4 Echo (ping): harmless, but disabling it hides the server from casual ping sweeps.

The traps

• Locking yourself out: a “block all” inbound rule applied over RDP, or a scoped rule with the wrong IP, ends your session. Always keep the provider console as a fallback and test from a second session.
• Disabled by third-party software: some security suites and a few provider images turn the firewall off. Re-enable it with Set-NetFirewallProfile -Profile Public -Enabled True.
• Wrong profile: a rule bound only to Domain silently does nothing on a Public network — bind rules to all three profiles unless you have a reason not to.
• Blocking outbound: aggressive outbound rules can break Windows Update and KMS activation. If you restrict outbound, allow 80/443 and the activation endpoints first.

A minimal hardening sequence

• Verify the firewall is enabled on all profiles: Get-NetFirewallProfile.
• Scope the RDP rule to your IP ranges (or disable the built-in rule and add a scoped one).
• Enable only the service rules you need: HTTP/HTTPS for IIS, 1433 for SQL Server if required.
• Add explicit block rules for anything you never want exposed, such as SMB (445) on a public interface.
• Test every change from a second session, and keep the provider console ready.

Verifying your work

After each change, confirm what is actually allowed: Get-NetFirewallRule -Direction Inbound -Enabled True | Where-Object Profile -like "*Public*" gives you the effective inbound surface. From another machine, Test-NetConnection <server-ip> -Port 3389 (or a port scan) confirms only the ports you intended are reachable. If a scan shows something unexpected, the rule list is the first place to look — and the second is the network profile assignment.

Bottom line

Windows Defender Firewall is already your default-deny perimeter; the job is to keep it on, scope what little you expose, and avoid the profile and lockout traps. That combination blocks most of the scan-and-exploit traffic that hits RDP and other services on a Windows VPS. If you are starting fresh and want a provider whose images keep the firewall intact and offer a console fallback, compare options in our Windows VPS comparison table and see the plans on our comparison page.

Ready to apply these rules on a new box? InterServer’s Windows VPS plans (promo code TRYINTERSERVER, penny first month) and Vultr’s Windows instances both give you full firewall control and out-of-band console access.