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.