How to Configure Windows Firewall Rules on Windows Server

Windows Defender Firewall is on by default on Windows Server, and it’s one of the few security controls that costs nothing and works out of the box. The mistake people make isn’t ignoring it — it’s turning it off the first time something doesn’t connect, instead of adding the right rule. A host firewall is what stops a compromised machine on your LAN from freely reaching RDP and SMB on every other server, so it’s worth configuring properly.

This guide covers both ways to manage firewall rules: the GUI (wf.msc) for one-off changes and visibility, and PowerShell’s New-NetFirewallRule and friends for anything you want to repeat or script. We’ll cover profiles, inbound and outbound rules, scoping rules to specific sources, and testing — plus the gotchas that lock people out of their own servers.

A quick warning up front: it’s entirely possible to firewall yourself out of a remote server. Read the locked-out section before you start changing rules on a box you only reach over RDP or WinRM.

How Windows Defender Firewall is structured#

Three concepts cover most of what you need.

Profiles. The firewall applies one of three profiles per network connection:

Default actions. Out of the box, inbound connections that don’t match an allow rule are blocked, and outbound connections are allowed. So most of your work is adding inbound allow rules for the services the server hosts.

Rules. Each rule has a direction (inbound/outbound), an action (allow/block), a protocol and port (or a program/service), and a scope (which addresses, profiles, and interfaces it applies to).

# See the current state and default actions for each profile
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

Creating rules in the GUI#

For a quick, visible change, the Windows Defender Firewall with Advanced Security console is fine.

1. Run wf.msc (Start > type “Windows Defender Firewall with Advanced Security”).
2. Select Inbound Rules > New Rule in the Actions pane.
3. Choose a rule type — usually Port (for a TCP/UDP port) or Program (for an executable).
4. Specify the protocol and port, e.g. TCP 443.
5. Choose Allow the connection (or allow only if secure, for IPsec).
6. Pick which profiles it applies to (Domain/Private/Public).
7. Name it something you’ll recognize later, like “Allow HTTPS inbound”.

The GUI is good for inspecting existing rules and understanding what’s already there. For anything you’ll do more than once, PowerShell is faster and repeatable.

Creating rules with PowerShell#

The NetSecurity module is the modern way to manage the firewall. New-NetFirewallRule is the core cmdlet.

Open a basic inbound port:

# Allow inbound HTTPS (TCP 443)
New-NetFirewallRule -DisplayName "Allow HTTPS Inbound" `
  -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

Scope it to a profile and a source subnet, which is far better than allowing the whole world:

# Allow RDP only from the admin subnet, Domain profile only
New-NetFirewallRule -DisplayName "Allow RDP from Admin Subnet" `
  -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Allow `
  -Profile Domain -RemoteAddress 10.0.50.0/24

Allow a specific program rather than a fixed port (useful for apps that pick dynamic ports):

# Allow a specific application to receive inbound traffic
New-NetFirewallRule -DisplayName "Allow App Server" `
  -Direction Inbound -Program "C:\Apps\MyService\service.exe" -Action Allow

Block something explicitly (block rules win over allow rules when both match):

# Block outbound SMB to the internet as a safety measure
New-NetFirewallRule -DisplayName "Block Outbound SMB to Internet" `
  -Direction Outbound -Protocol TCP -RemotePort 445 -Action Block `
  -RemoteAddress Internet

Managing existing rules#

You rarely just create rules. You also adjust, disable, and inspect them.

# Find rules by name pattern
Get-NetFirewallRule -DisplayName "*RDP*" | Select-Object DisplayName, Enabled, Direction, Action

# Tighten an existing rule's source scope (e.g. the built-in Remote Desktop group)
Set-NetFirewallRule -DisplayGroup "Remote Desktop" -RemoteAddress 10.0.50.0/24

# Disable a rule without deleting it
Disable-NetFirewallRule -DisplayName "Allow HTTPS Inbound"

# Re-enable it later
Enable-NetFirewallRule -DisplayName "Allow HTTPS Inbound"

# Remove a rule entirely
Remove-NetFirewallRule -DisplayName "Allow App Server"

To see the port and address filters attached to a rule (the details aren’t on the rule object itself, they’re on associated filter objects):

# Inspect the port filter for a rule
Get-NetFirewallRule -DisplayName "Allow RDP from Admin Subnet" |
  Get-NetFirewallPortFilter

# Inspect the address scope for a rule
Get-NetFirewallRule -DisplayName "Allow RDP from Admin Subnet" |
  Get-NetFirewallAddressFilter

Don’t lock yourself out#

This is the part that catches people. If you manage a server only over RDP or WinRM and you change firewall rules carelessly, you can cut your own connection and have no way back in short of console access.

A few habits that prevent it:

• Never create a broad inbound block rule, or change the default inbound action to block-all, without first confirming your management port (RDP 3389 or WinRM 5985/5986) has an explicit allow rule scoped to your source.
• When tightening RDP with -RemoteAddress, make sure your own admin host or subnet is included in the allowed range.
• Test changes on a non-critical server, or one you can reach via console (iLO/iDRAC/Hyper-V/VM console), first.

Profile-level settings#

Sometimes you want to change behavior for a whole profile rather than per rule.

# Make sure the firewall is enabled on all profiles
Set-NetFirewallProfile -Profile Domain,Private,Public -Enabled True

# Enable logging of dropped packets for the Domain profile (useful for troubleshooting)
Set-NetFirewallProfile -Profile Domain `
  -LogBlocked True -LogFileName "%SystemRoot%\System32\LogFiles\Firewall\pfirewall.log"

In a domain, you’ll often manage firewall rules centrally with Group Policy instead of per server, so every server of a given role gets the same baseline. Local rules and GPO rules merge by default, but you can configure policy so GPO rules take precedence. If GPO firewall settings aren’t taking effect, the usual culprits are the same as any policy problem — see why Group Policy isn’t applying and how to fix it.

Testing your rules#

Don’t assume a rule works because it exists. Verify from the client side.

# From a client: test whether a TCP port is reachable on the server
Test-NetConnection -ComputerName fileserver01 -Port 445

# On the server: confirm something is actually listening on the port
Get-NetTCPConnection -State Listen -LocalPort 443

Test-NetConnection tells you whether the port is open and reachable end to end. If it fails, check in order: the service is running and listening, the inbound allow rule exists and is enabled, the rule’s profile matches the active profile, and the -RemoteAddress scope includes the client.

Wrapping up#

Configuring Windows Defender Firewall on Windows Server comes down to a simple loop: leave it enabled, add specific inbound allow rules for the services you run, scope sensitive ports to known sources, and test from the client. New-NetFirewallRule makes all of that repeatable, which is what you want once you’re managing more than a handful of servers.

The two rules that save you the most pain: never disable the firewall to “fix” a connection, and never tighten rules on a remote-only server without first confirming your own management path stays open. Get those right and the firewall becomes a quiet, useful layer instead of something you fight.