Fix 'Windows Defender Firewall has blocked some features of this app' on Windows

The Error

You launch an app — a local dev server, a game, a database tool — and Windows pops up:

Windows Defender Firewall has blocked some features of this app

Sometimes you click "Allow" and the app still can't accept connections. Sometimes the dialog never shows at all and the app silently fails to bind. Either way, traffic isn't getting through.

Root Cause

By default, Windows Defender Firewall blocks all inbound connections for any app that hasn't been explicitly allowed. The first time an app tries to listen on a port, Windows prompts you. Click "Cancel" — or run the app via a service with no desktop session — and no rule gets created. The app is silently blocked from that point on.

Common scenarios where this bites people:

• A Node.js / Python / Go dev server on port 3000 or 8080 that other devices on the network can't reach
• A game or peer-to-peer app that can't accept incoming connections
• A local database (PostgreSQL on 5432, Redis on 6379) unreachable from another machine on the same LAN
• The app was reinstalled to a new path — the old firewall rule still points to the old location and never matches
• A script or scheduler launched the app without a desktop session, so the prompt was never shown

Fix 1 — Allow the App Through the Firewall GUI

Start here if you want to unblock a specific app without touching PowerShell:

• Open Windows Security → Firewall & network protection → Allow an app through firewall
• Click Change settings (admin required)
• Find your app in the list. Check Private and/or Public as needed
• Not listed? Click Allow another app… → browse to the .exe → Add

Windows creates a firewall rule tied to that executable's path.

Fix 2 — Add an Inbound Rule for a Specific Port (PowerShell)

Got a server on a known port? A port-based rule is tighter than allowing the whole executable.

# Allow TCP port 3000 inbound (e.g. a dev server)
New-NetFirewallRule `
  -DisplayName "Dev Server Port 3000" `
  -Direction Inbound `
  -Protocol TCP `
  -LocalPort 3000 `
  -Action Allow `
  -Profile Any

For UDP or a range of ports:

# UDP, port range 7000-7100
New-NetFirewallRule `
  -DisplayName "Game Ports UDP" `
  -Direction Inbound `
  -Protocol UDP `
  -LocalPort 7000-7100 `
  -Action Allow `
  -Profile Private

Run PowerShell as Administrator for both commands.

Fix 3 — Add an Inbound Rule for the Executable (PowerShell)

Dynamic ports? Allow the executable itself rather than pinning a port number:

New-NetFirewallRule `
  -DisplayName "Allow MyApp" `
  -Direction Inbound `
  -Program "C:\Program Files\MyApp\myapp.exe" `
  -Action Allow `
  -Profile Any

Prefer classic cmd? netsh works too, and runs on older Windows versions:

netsh advfirewall firewall add rule ^
  name="Allow MyApp" ^
  dir=in ^
  action=allow ^
  program="C:\Program Files\MyApp\myapp.exe" ^
  enable=yes

Fix 4 — Check If a Rule Exists But Is Disabled

Before creating anything new, check whether a rule already exists and is just disabled:

# List all inbound rules
Get-NetFirewallRule -Direction Inbound | Select-Object DisplayName, Enabled, Action

# Filter by name keyword
Get-NetFirewallRule -Direction Inbound | Where-Object { $_.DisplayName -like "*MyApp*" }

Found a disabled rule? One command to re-enable it:

Set-NetFirewallRule -DisplayName "Allow MyApp" -Enabled True

Fix 5 — Temporarily Disable Firewall for Testing

Not sure the firewall is even the problem? Disable it briefly to confirm, then turn it back on immediately.

# Disable firewall on all profiles (testing only)
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled False

# Re-enable right after testing
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

App works with the firewall off? That's your confirmation. Add a proper rule and re-enable — don't leave it disabled.

Verification

After adding a rule, confirm it actually worked:

# Is your app listening on the expected port?
netstat -ano | findstr :3000

# Same check via PowerShell
Get-NetTCPConnection -LocalPort 3000

From another machine on the same network:

# Windows (PowerShell)
Test-NetConnection -ComputerName 192.168.1.100 -Port 3000

# Linux / macOS
nc -zv 192.168.1.100 3000

TcpTestSucceeded : True means the port is open and reachable. Done.

Prevention

A few small habits that prevent this from recurring:

• Firewall rules are tied to the executable path. If you reinstall the app to a different folder or rename the directory, the old rule stops matching — silently. Document which rules you added and when, so cleanup is straightforward.
• Scope rules to Private network only where possible. A dev server on port 3000 doesn't need to be reachable on the Public profile. Keep that exposure minimal.
• Use specific display names. "Dev Server Port 3000" is easier to audit in six months than "New Rule 4". Helps a lot when cleaning up stale rules.
• Scoping a rule to a specific subnet? The Subnet Calculator on ToolCraft calculates CIDR ranges instantly — useful when you want to allow only 192.168.1.0/24 instead of any source. Browser-based, nothing leaves your machine.

Clean Up Old Rules

Firewall rules accumulate fast. Audit and remove the ones that no longer apply:

# Remove a rule by display name
Remove-NetFirewallRule -DisplayName "Old Dev Server"

# Find rules tied to a specific program
Get-NetFirewallRule -Direction Inbound | `
  Get-NetFirewallApplicationFilter | `
  Where-Object { $_.Program -like "*node*" }