How to Configure Windows Firewall: Security Rules for Windows Server

Overview

Windows Firewall (formally called Windows Defender Firewall with Advanced Security) controls what network traffic is allowed into and out of your server. Every Windows Server deployment — whether it’s a self-managed VPS or a Dedicated Server — ships with it enabled by default, but the default rules are often too permissive for production use.

Most people interact with Windows Firewall only when something stops working — a web app can’t reach a database, RDP suddenly drops, or a monitoring agent can’t phone home. Understanding how to read and write firewall rules proactively saves you hours of that kind of debugging.

This article covers Windows Server 2019 and 2022, using both the GUI (Windows Defender Firewall with Advanced Security) and PowerShell. The concepts apply to Windows Server 2016 as well, with minor UI differences.

Prerequisites

• Administrator access to the Windows Server instance
• Remote Desktop (RDP) or direct console access
• Windows Server 2016, 2019, or 2022
• Basic understanding of TCP/UDP ports (helpful but not required — explained inline)
• If you’re managing rules remotely, make sure your RDP rule is intact before making changes — locking yourself out is easier than it sounds

Step-by-Step Instructions

Step 1: Open Windows Defender Firewall with Advanced Security

The basic Windows Firewall panel (Control Panel → System and Security → Windows Defender Firewall) only gives you on/off toggles. You need the Advanced Security console for real rule management.

Press Win + R, type the following, and press Enter:

wf.msc

Alternatively, open Server Manager → Tools → Windows Defender Firewall with Advanced Security.

You’ll see three panels: the left navigation tree (Inbound Rules, Outbound Rules, Connection Security Rules), a centre list of existing rules, and a right Actions panel.

Step 2: Understand the Rule Types Before You Touch Anything

Windows Firewall evaluates rules in this order: explicit block rules win, then explicit allow rules, then the default profile action (block or allow all). This matters because adding an allow rule won’t override an existing block rule for the same port — the block wins.

• Inbound rules — control traffic coming into your server (e.g. HTTP on port 80, RDP on port 3389)
• Outbound rules — control traffic leaving your server (e.g. blocking your server from calling out on port 25 to prevent spam relay)
• Connection Security Rules — handle IPsec authentication; you generally won’t touch these unless you’re setting up a VPN or domain environment

📝 Note: Windows Firewall uses three profiles — Domain, Private, and Public. On a standalone server not joined to a domain, your rules typically apply to the Public or Private profile. Check which profile your network adapter is using before you write rules — a rule scoped to the wrong profile does nothing.

Step 3: Create an Inbound Rule to Allow a Port

This is the most common task. Example: you’ve installed a web application that listens on port 8080, and it’s not reachable from outside.

1. In wf.msc, right-click Inbound Rules in the left panel and select New Rule.
2. Select Port and click Next.
3. Select TCP, enter 8080 under Specific local ports, and click Next.
4. Select Allow the connection and click Next.
5. Check all three profiles (Domain, Private, Public) unless you have a specific reason to restrict it. Click Next.
6. Give the rule a descriptive name like Allow TCP 8080 - Web App. Good naming saves you when you’re troubleshooting at 2 AM.
7. Click Finish.

To do the same thing in PowerShell (faster when you’re already in a remote session):

New-NetFirewallRule `
  -DisplayName "Allow TCP 8080 - Web App" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 8080 `
  -Action Allow `
  -Profile Any

Step 4: Create an Inbound Rule to Block a Port or IP Address

Blocking specific IPs is useful when you’re seeing repeated failed login attempts on RDP or SSH-equivalent services. Here’s how to block an IP from reaching your server entirely:

New-NetFirewallRule `
  -DisplayName "Block Abusive IP 203.0.113.45" `
  -Direction Inbound `
  -RemoteAddress 203.0.113.45 `
  -Action Block `
  -Profile Any

⚠ Warning: Block rules always win over allow rules for the same traffic. If you accidentally block your own IP, you’ll lose access. Before running any block rule against a broad IP range, verify your own public IP is excluded.

Step 5: Restrict RDP Access to Specific IP Addresses

This is one of the single most effective things you can do to harden a Windows server. Leaving RDP open to the world (port 3389, all sources) is asking for brute-force attacks. I’d strongly recommend scoping it to your office IP or your management VPN range.

First, find the existing RDP allow rule. In wf.msc → Inbound Rules, look for Remote Desktop – User Mode (TCP-In). Double-click it.

1. Go to the Scope tab.
2. Under Remote IP address, select These IP addresses.
3. Click Add and enter your trusted IP or CIDR range (e.g. 198.51.100.0/24).
4. Click OK to save.

PowerShell equivalent:

Set-NetFirewallRule `
  -DisplayName "Remote Desktop - User Mode (TCP-In)" `
  -RemoteAddress 198.51.100.0/24

📝 Note: If you’re on a dynamic home IP, set a reminder to update this rule when your IP changes — otherwise you’ll lock yourself out and need console access to fix it. On a Host & Tech dedicated server, you can use the IPMI/KVM console to recover access in that situation.

Step 6: Create an Outbound Rule

By default, Windows Firewall allows all outbound traffic. On a production server, you might want to block outbound SMTP (port 25) to prevent a compromised application from sending spam, or restrict outbound traffic to known destinations only.

To block outbound port 25 (SMTP) except to your authorised mail relay:

# First, block all outbound port 25
New-NetFirewallRule `
  -DisplayName "Block Outbound SMTP 25" `
  -Direction Outbound `
  -Protocol TCP `
  -RemotePort 25 `
  -Action Block `
  -Profile Any

# Then allow it specifically to your mail relay IP
New-NetFirewallRule `
  -DisplayName "Allow Outbound SMTP to Mail Relay" `
  -Direction Outbound `
  -Protocol TCP `
  -RemotePort 25 `
  -RemoteAddress 192.0.2.10 `
  -Action Allow `
  -Profile Any

⚠ Warning: Remember — block rules win. The block-all rule above will override the allow rule for the relay IP unless you’re careful. In Windows Firewall, a more specific allow rule does NOT automatically take priority over a broader block rule. You need to set rule priority manually by moving the allow rule above the block rule in the list, or use the -Priority parameter approach with Set-NetFirewallRule.

Actually, the cleanest approach here is to set the allow rule first (lower rule number = higher priority in the list), then set the block. In the GUI, you can drag rules to reorder them within the same action type — but allow vs. block priority is handled by action type, not position. The real gotcha: Block always beats Allow for the same traffic match, so you need to make the allow rule more specific (narrower scope) than the block rule. The relay-specific rule above is already more specific, so it will work correctly.

Step 7: Export and Back Up Your Firewall Rules

Before deploying to production or making bulk changes, export your current ruleset. You’ll thank yourself later.

netsh advfirewall export "C:Backupsfirewall-backup.wfw"

To restore it:

netsh advfirewall import "C:Backupsfirewall-backup.wfw"

Common Issues & Troubleshooting

Port is open in the firewall but still unreachable from outside

The firewall rule exists and looks correct, but connections on that port still time out from an external machine. The most common cause isn’t the Windows Firewall at all — it’s a network-level firewall or security group sitting in front of the server. On Host & Tech dedicated servers and VPS plans, check whether there’s a hardware firewall or ACL configured in your control panel. The Windows Firewall rule is only one layer. Also verify the application is actually bound to the correct interface and port using:

netstat -ano | findstr :8080

If nothing shows up, the app isn’t listening — the firewall isn’t the problem.

RDP connection drops immediately after login

You connect via RDP, see the desktop briefly, then get disconnected. This is often caused by a firewall rule that allows the initial TCP handshake but blocks follow-up traffic, or a Group Policy that’s overwriting your custom rules. Run gpresult /h C:gp-report.html to check applied policies. Also check that the Remote Desktop – Shadow (TCP-In) and Remote Desktop – User Mode (UDP-In) rules are enabled alongside the TCP rule.

Windows Firewall rules keep resetting after reboot

Group Policy is almost always the culprit. If your server is domain-joined, a GPO can overwrite local firewall rules on every policy refresh cycle (every ~90 minutes, plus at boot). Local rules you set manually will get wiped. You need to either configure firewall rules through Group Policy itself, or check with your domain admin to understand what policy is being applied. Use gpresult /r to see which GPOs are active.

Allow rule exists but traffic is still blocked

Check for a conflicting block rule. In wf.msc, right-click the top-level Windows Defender Firewall with Advanced Security node and select Properties. Under each profile tab, check the Inbound connections setting — if it says Block (default), any traffic without an explicit allow rule is dropped. More commonly though, there’s a block rule you’ve forgotten about. Filter the inbound rules list by the relevant port to see everything that applies.

Firewall is blocking traffic but Windows Firewall shows it as disabled

This one trips people up. A third-party security product (CrowdStrike, Sophos, Windows Defender for Endpoint in certain configurations) can enforce network filtering independently of the Windows Firewall service state. Check Windows Security → Firewall & network protection to see if a third-party firewall is listed as active. Also check: Get-NetFirewallProfile | Select-Object Name, Enabled in PowerShell to confirm actual profile states.

FAQ