How to Configure Windows Firewall Rules Properly

This creates specific, properly-scoped Windows Firewall rules — the correct alternative to the common (and risky) shortcut of just disabling the firewall entirely to make an application work.

Step 1: check current firewall status across all profiles

Get-NetFirewallProfile | Select-Object Name, Enabled

Windows Firewall maintains separate profiles for Domain, Private, and Public networks — a rule (or the firewall itself) can be enabled differently across each, which is exactly why “it works at home but not at the office” or vice versa is a common symptom worth checking against this output first.

Step 2: find out what’s actually being blocked

Rather than guessing, check the Windows Firewall security log for recent drops, if logging is enabled:

Get-NetFirewallProfile -Profile Domain,Private,Public | Select-Object Name, LogBlocked, LogFileName

Set-NetFirewallProfile -Profile Private -LogBlocked True -LogFileName "%systemroot%\system32\LogFiles\Firewall\pfirewall.log"

Enabling blocked-connection logging, reproducing the failure, then checking the log file gives you the exact port and direction that’s actually being blocked, rather than guessing.

Step 3: create a specific inbound rule for an application

Rather than a blanket “allow everything,” scope a rule to exactly what’s needed — a specific program and port:

New-NetFirewallRule -DisplayName "My App - Inbound" `
  -Direction Inbound `
  -Program "C:\Program Files\MyApp\myapp.exe" `
  -Protocol TCP -LocalPort 8080 `
  -Action Allow `
  -Profile Private

Scoping to -Profile Private specifically (rather than all profiles) means this rule only applies on networks marked as private/trusted — a reasonable default unless you specifically need the same access on public networks too.

Step 4: create a rule scoped to specific remote addresses, when possible

If the application only needs to be reached from a known, specific set of machines (an internal admin tool, for instance), scope the rule further by remote address rather than allowing any source:

New-NetFirewallRule -DisplayName "Admin Tool - Restricted" `
  -Direction Inbound `
  -Protocol TCP -LocalPort 9090 `
  -RemoteAddress 192.168.1.0/24 `
  -Action Allow

Step 5: verify the rule is actually active and correctly scoped

Get-NetFirewallRule -DisplayName "My App - Inbound" | Get-NetFirewallPortFilter
Get-NetFirewallRule -DisplayName "My App - Inbound" | Get-NetFirewallApplicationFilter

Step 6: test from another machine, not just locally

Test-NetConnection -ComputerName yourserver -Port 8080

Run this from a separate machine on the network — testing against localhost from the same machine doesn’t exercise the inbound firewall rule the same way genuine external traffic does.

Step 7: clean up temporary or testing rules

Remove-NetFirewallRule -DisplayName "Admin Tool - Restricted"

Rules created for testing or troubleshooting that are no longer needed should be removed rather than left accumulating — an old, forgotten allow rule is exactly the kind of thing a later security review has to spend time investigating.

Why scoped rules, not disabling the firewall

Disabling Windows Firewall entirely to fix “an app can’t connect” removes every protection it provides system-wide, for every application, indefinitely — usually to solve what’s actually a single missing rule for one specific port. A properly scoped New-NetFirewallRule — specific program, specific port, specific profile, and ideally a specific remote address range — solves the actual connectivity problem while leaving every other protection intact, and is barely more effort than the blanket “just turn it off” shortcut once you have the pattern down.

Creating an outbound rule, and why outbound is usually more restrictive by default

New-NetFirewallRule -DisplayName "Block Outbound - Legacy App" `
  -Direction Outbound `
  -Program "C:\Program Files\LegacyApp\legacyapp.exe" `
  -Action Block `
  -Profile Any

Windows Firewall’s default policy is considerably more permissive outbound than inbound — most outbound traffic is allowed by default, on the assumption that software running locally on a trusted machine generally has a legitimate reason to reach out, while unsolicited inbound connections are the higher-risk default to block. Creating explicit outbound block rules is less common than inbound allow rules, but genuinely useful for specific scenarios — preventing a legacy application with no legitimate need for network access from phoning home at all, or enforcing that only an approved, curated list of applications can reach the network outbound on a security-sensitive machine.

Exporting and importing a firewall configuration for consistency across machines

Copy-NetFirewallRule -PolicyStore "C:\firewall-backup.wfw"
netsh advfirewall export "C:\firewall-backup.wfw"
netsh advfirewall import "C:\firewall-backup.wfw"

For deploying an identical, carefully-reviewed set of firewall rules consistently across multiple machines — rather than manually recreating each New-NetFirewallRule command on every machine individually — exporting a known-good configuration and importing it elsewhere ensures every machine ends up with byte-for-byte identical rules, avoiding the small configuration drift that inevitably creeps in when rules are hand-typed separately on each machine over time.

Auditing existing rules for scope creep periodically

Get-NetFirewallRule -Direction Inbound -Action Allow -Enabled True |
  Where-Object { $_.Profile -match "Public" } |
  Select-Object DisplayName, Profile

Over time, a machine can accumulate broad or forgotten allow rules — a temporary testing rule never removed (Step 7), or a rule created broader than actually necessary under time pressure during an earlier troubleshooting session. Periodically reviewing rules specifically scoped to the Public profile (the highest-risk network context, since it applies on untrusted networks like public Wi-Fi) for anything unexpectedly broad or no longer actually needed is a reasonable recurring audit habit, catching accumulated scope creep before it becomes a genuine, exploitable gap rather than only reviewing firewall configuration reactively after an incident has already occurred.

Related:

Sources: