How to Configure Windows Firewall with Advanced Security on Windows Server 2022
Windows Defender Firewall with Advanced Security is a host-based, stateful firewall built into every edition of Windows Server 2022. Unlike the basic firewall panel in Control Panel, the Advanced Security console exposes the full rule engine: inbound and outbound rules, connection security rules, and IPsec policies. Mastering this tool is essential for hardening servers, meeting compliance requirements, and controlling lateral movement inside a network. This guide walks through the graphical console, PowerShell cmdlets, and the classic netsh advfirewall interface.
Opening Windows Firewall with Advanced Security
The management console is wf.msc. You can open it from Run, from Server Manager under Tools, or directly from PowerShell:
wf.msc
Alternatively, open it through the Control Panel path: Control Panel → System and Security → Windows Defender Firewall → Advanced settings. The left pane shows the three main nodes: Inbound Rules, Outbound Rules, and Connection Security Rules. The root node displays the active profile and a quick overview of the firewall state for each profile.
Understanding Firewall Profiles
Windows Firewall maintains three separate profiles, and each network adapter is assigned to exactly one profile at any moment. Each profile can have completely different rules and default actions.
Domain profile: Applied when the computer can authenticate against an Active Directory domain controller. This is the profile that fires on domain-joined servers in a corporate environment and is typically the least restrictive because the domain controller provides additional trust.
Private profile: Applied when the network is marked Private by a user or administrator. Used for home networks and trusted internal segments that are not domain-joined.
Public profile: Applied for all other network connections — cloud VMs, untrusted Wi-Fi, DMZ interfaces. This profile should be the most restrictive. On Windows Server 2022, new rules should not be created for Public unless explicitly required.
To view and change the state of each profile from PowerShell, use Get-NetFirewallProfile:
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction
To enable or disable a specific profile:
Set-NetFirewallProfile -Profile Domain,Private -Enabled True
Set-NetFirewallProfile -Profile Public -Enabled True -DefaultInboundAction Block
Viewing Existing Firewall Rules
PowerShell’s Get-NetFirewallRule returns all rules in the policy store. Without parameters it returns every rule — several hundred on a default server installation — so always filter:
# Show only enabled inbound rules
Get-NetFirewallRule -Direction Inbound -Enabled True | Select-Object DisplayName, Action, Profile
# Find rules by display name (wildcards supported)
Get-NetFirewallRule -DisplayName "*Remote Desktop*"
# Show the port filter associated with a rule
Get-NetFirewallRule -DisplayName "World Wide Web Services (HTTP Traffic-In)" |
Get-NetFirewallPortFilter
The Get-NetFirewallPortFilter, Get-NetFirewallAddressFilter, and Get-NetFirewallApplicationFilter cmdlets retrieve the filter objects associated with a rule. These are stored separately from the rule object itself, which is why you pipe the rule into the filter cmdlet.
Creating Inbound Rules with New-NetFirewallRule
The most common task is opening a specific TCP or UDP port to allow traffic from a defined source. The New-NetFirewallRule cmdlet accepts dozens of parameters. The most important are -DisplayName, -Direction, -Protocol, -LocalPort, -RemoteAddress, -Action, and -Profile.
Allow inbound HTTPS (TCP 443) from any source on the Domain and Private profiles:
New-NetFirewallRule `
-DisplayName "Allow Inbound HTTPS" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 443 `
-Action Allow `
-Profile Domain,Private `
-Enabled True
Allow inbound SQL Server traffic (TCP 1433) only from a specific management subnet:
New-NetFirewallRule `
-DisplayName "Allow SQL Server from Management VLAN" `
-Direction Inbound `
-Protocol TCP `
-LocalPort 1433 `
-RemoteAddress 10.10.50.0/24 `
-Action Allow `
-Profile Domain `
-Enabled True
Block outbound traffic to a known malicious IP range:
New-NetFirewallRule `
-DisplayName "Block Outbound to Suspicious Range" `
-Direction Outbound `
-RemoteAddress 198.51.100.0/24 `
-Action Block `
-Profile Any `
-Enabled True
Modifying Existing Rules with Set-NetFirewallRule
Set-NetFirewallRule modifies one or more existing rules. You can reference rules by their -DisplayName or by their internal -Name (the GUID-based identifier). Wildcards work in -DisplayName.
# Disable a rule without deleting it
Set-NetFirewallRule -DisplayName "Allow Inbound HTTPS" -Enabled False
# Change the action of a rule from Allow to Block
Set-NetFirewallRule -DisplayName "Allow Inbound HTTPS" -Action Block
# Restrict an existing rule to a specific remote address
Set-NetFirewallRule -DisplayName "Allow Inbound HTTPS" -RemoteAddress 192.168.1.0/24
# Enable all rules belonging to a group
Set-NetFirewallRule -Group "Remote Desktop" -Enabled True -Profile Domain
Connection Security Rules and IPsec Policies
Connection security rules live under the Connection Security Rules node in wf.msc. They enforce IPsec negotiation between endpoints — authentication, encryption, or both — before traffic is allowed. These rules do not allow or block traffic by themselves; they work alongside firewall rules.
Common use cases include server isolation (requiring all inbound connections to authenticate with Kerberos or certificate-based IPsec) and domain isolation (limiting communication to domain-joined computers).
Create an isolation rule that requires inbound connections to authenticate before being accepted:
New-NetIPsecRule `
-DisplayName "Require Inbound IPsec Authentication" `
-InboundSecurity Require `
-OutboundSecurity Request `
-Phase1AuthSet (New-NetIPsecAuthProposal -Machine -Kerberos | New-NetIPsecMainModeAuthSet -DisplayName "KerbAuthSet").Name `
-Profile Domain
View all connection security rules:
Get-NetIPsecRule | Select-Object DisplayName, InboundSecurity, OutboundSecurity, Enabled
Exporting and Importing Firewall Policy
Exporting the firewall configuration captures all rules and settings to a binary .wfw file or to a Group Policy object. This is critical for backup and for deploying a tested policy to additional servers.
Export the entire local firewall policy:
netsh advfirewall export "C:Backupfirewall-policy-$(Get-Date -Format yyyyMMdd).wfw"
Import the policy on another server (this overwrites the existing policy):
netsh advfirewall import "C:Backupfirewall-policy-20260101.wfw"
To reset the firewall to Windows defaults — useful when a misconfigured policy locks you out over RDP — run:
netsh advfirewall reset
Warning: The reset command removes all custom rules immediately. Always confirm you have console access before running this on a production server.
Working with netsh advfirewall
The netsh advfirewall context predates PowerShell cmdlets and is still useful in scripts that must run on older OS versions or in WinPE environments. On Windows Server 2022 both interfaces write to the same policy store.
# Show the current state of all profiles
netsh advfirewall show allprofiles
# Add an inbound rule allowing TCP 8080
netsh advfirewall firewall add rule name="Allow TCP 8080 Inbound" ^
dir=in action=allow protocol=TCP localport=8080
# Delete a rule by name
netsh advfirewall firewall delete rule name="Allow TCP 8080 Inbound"
# Show all inbound rules
netsh advfirewall firewall show rule name=all dir=in
# Set the Domain profile to block inbound by default
netsh advfirewall set domainprofile firewallpolicy blockinbound,allowoutbound
Logging Firewall Events
Firewall logging records dropped packets and successful connections to a text file. This is invaluable for troubleshooting blocked application traffic and for detecting port scans.
Enable logging for the Domain profile via PowerShell:
Set-NetFirewallProfile -Profile Domain `
-LogFileName "C:WindowsSystem32LogFilesFirewallpfirewall.log" `
-LogMaxSizeKilobytes 4096 `
-LogAllowed True `
-LogBlocked True
Enable logging through netsh:
netsh advfirewall set domainprofile logging filename C:WindowsSystem32LogFilesFirewallpfirewall.log
netsh advfirewall set domainprofile logging maxfilesize 4096
netsh advfirewall set domainprofile logging droppedconnections enable
netsh advfirewall set domainprofile logging allowedconnections enable
The log file uses a W3C-compatible format. Each line contains a timestamp, direction, source IP, destination IP, source port, destination port, protocol, and action. You can parse it with Get-Content and PowerShell’s -match operator or import it into a SIEM.
Deploying Rules via Group Policy
For domain environments, the recommended approach is to configure firewall rules in a Group Policy Object (GPO) rather than directly on each server. Navigate to: Computer Configuration → Windows Settings → Security Settings → Windows Defender Firewall with Advanced Security. Rules defined here are merged with local rules by default. You can enforce a GPO-only policy by setting the merge behavior to prevent local rule creation.
# Force policy refresh immediately after applying a GPO
gpupdate /force
# Confirm which policy store the active rules came from
Get-NetFirewallRule | Where-Object {$_.PolicyStoreSourceType -eq "GroupPolicy"} |
Select-Object DisplayName, Direction, Action | Format-Table -AutoSize
Best Practices for Windows Server 2022 Firewall
Start with a deny-all default inbound stance and add explicit allow rules for each required service. Never disable the firewall entirely, even temporarily — instead, create a rule that allows all traffic from your management source IP. Use the -RemoteAddress parameter to scope administrative access rules (RDP, WinRM, SSH) to specific management hosts or subnets. Document every rule with a meaningful -DisplayName and optionally a -Description so future administrators understand intent. Audit the firewall configuration periodically with Get-NetFirewallRule to remove stale rules left by uninstalled applications. Use connection security rules for east-west server-to-server communication in sensitive environments rather than relying solely on perimeter firewalls.