Windows · Host Firewall

Windows Firewall with Advanced Security

Windows Firewall with Advanced Security is the host-based packet filter built into every modern Windows client and server, and understanding its three profiles and rule-precedence logic explains almost every “it works on one network but not another” ticket you will see.

By K Shankar R Karanth Windows Active Directory

Quick idea: Windows Firewall with Advanced Security blocks all unsolicited inbound traffic by default and evaluates every connection against a profile-specific rule set — Domain, Private, or Public — chosen automatically based on what kind of network the machine thinks it is on. Most firewall tickets come down to the wrong profile being active or a rule that was never staged before the application needed it.

wf.msc

The MMC snap-in that opens the Advanced Security console directly.

Profiles

Domain, Private, and Public — each with its own enabled state and rule set.

NetSecurity module

The PowerShell cmdlets (New-NetFirewallRule, and friends) that replace netsh advfirewall.

What Is Windows Firewall with Advanced Security?

Windows Firewall with Advanced Security (often shortened to WFAS) is the stateful, host-based packet filter built into every supported version of Windows client and server. It sits between the network stack and every application on the machine, deciding — connection by connection — whether traffic is allowed to reach a listening process or leave the machine at all.

Think of it as a security guard posted at every door of the building rather than one guard at the perimeter fence. A network firewall protects the edge of the network; a host firewall like this one protects each machine individually, so a compromised or misconfigured device on the inside of your network still cannot freely reach every other host.

The console you configure it from is the Windows Defender Firewall with Advanced Security MMC snap-in, reachable by running wf.msc, or via Control Panel > System and Security > Windows Defender Firewall > Advanced settings. The basic Control Panel applet next to it only exposes on/off switches and a handful of app permissions; the Advanced Security console is where inbound rules, outbound rules, connection security rules, and per-profile behaviour actually live.

Important: Microsoft explicitly recommends against disabling Windows Firewall by stopping its service (display name Windows Defender Firewall, service name MpsSvc). Doing so is unsupported and can break the Start menu, modern app installs and updates, and Windows activation. If a profile genuinely needs to be off, disable that profile instead and leave the service running.

How the Three Profiles Work

Every network a Windows machine connects to is classified into one of three profiles, and the firewall applies a different rule set depending on which profile is currently active on a given network adapter.

Domain

Applied automatically when the machine is domain-joined and can reach a domain controller. Cannot be set manually.

Private

For trusted networks like a home or small-office LAN. An administrator sets this manually per network.

Public

The default and most restrictive profile for unidentified networks — coffee shops, hotel Wi-Fi, anything unrecognised.

This matters operationally because a laptop that is fine on the corporate LAN can fail the same file share or RDP connection the moment it is on a hotel network, simply because the active profile switched from Domain to Public and the relevant rule is only enabled for the first two. Rules can be created in all three profiles at once but selectively enabled per profile, which is exactly the intended pattern for anything that should not be reachable from an untrusted network.

How Rule Evaluation Actually Works

Windows Firewall does not support administrator-assigned rule ordering the way some network firewalls do. Instead, every connection is evaluated against a small, fixed set of precedence behaviours, and understanding them prevents a lot of confused troubleshooting later:

Rule	Effect
1	An explicit allow rule overrides the default block behaviour.
2	An explicit block rule always overrides a conflicting allow rule, regardless of specificity.
3	Where no block rule conflicts, the more specific rule wins — a single-host rule beats a subnet-range rule.

Outbound rules follow the identical logic. The practical consequence of rule 2 is the one that catches people out: a broad block rule created for one purpose can silently swallow a narrow allow rule created for something else entirely, and there is no way to reorder them to fix it — the only fix is to scope the block rule more tightly or remove the overlap.

Practical rule: Inbound is default-block and should stay that way even in high-security environments. Outbound is default-allow on most deployments for practical reasons; only flip it to default-block if you are prepared to maintain a full inventory of every application that needs to talk out, because nothing else works until you do.

Rule Types and How They Get Created

A rule can match traffic by program path, by port and protocol, by a predefined Windows service or feature (the entries you see grouped by name in the console), or by a fully custom combination of program, port, protocol, and address scope. Most rules on a typical machine were never created by an administrator at all — they were created automatically the first time an application issued a listen call and Windows prompted the user to allow or block it.

That automatic behaviour is convenient on a single-user machine and a liability at scale. If a non-administrative user is prompted, Windows creates a block rule no matter what they click. If notifications are disabled outright, no rule is created either way and the traffic simply stays blocked by the default. For any managed fleet, the reliable pattern is to stage the required allow rules centrally — via Group Policy or Intune — before users ever launch the application, and disable the inbound notification prompt so a confused click cannot quietly create a permanent block rule.

Configuring It: Console and PowerShell

Everything in this section can be done from the wf.msc console by hand, but any environment with more than a handful of machines should manage this through Group Policy or the NetSecurity PowerShell module rather than clicking through the GUI machine by machine.

# Confirm the firewall service and profile states
Get-NetFirewallProfile | Select-Object Name, Enabled, DefaultInboundAction, DefaultOutboundAction

# Enable the firewall on all three profiles
Set-NetFirewallProfile -Profile Domain,Public,Private -Enabled True

# Set the standard default posture: block inbound, allow outbound,
# and stop prompting users when an app is blocked from listening
Set-NetFirewallProfile -DefaultInboundAction Block -DefaultOutboundAction Allow -NotifyOnListen False

# Allow an application to listen inbound, scoped to the local subnet only
New-NetFirewallRule -DisplayName "Allow Inbound App Server" -Direction Inbound -Program "C:\Program Files\App\app.exe" -RemoteAddress LocalSubnet -Action Allow

# Block a specific outbound port for a specific program
New-NetFirewallRule -DisplayName "Block Outbound Telnet" -Direction Outbound -Program "%SystemRoot%\System32\tlntsvr.exe" -Protocol TCP -LocalPort 23 -Action Block

# List every rule that currently blocks traffic
Get-NetFirewallRule -Action Block

# Enable or disable an entire predefined rule group at once
Enable-NetFirewallRule -DisplayGroup "Remote Desktop"
Disable-NetFirewallRule -DisplayGroup "Remote Desktop"

# Remove a rule by its display name
Remove-NetFirewallRule -DisplayName "Allow Inbound App Server"

Better approach: To push rules to every domain-joined machine at once, write them directly into a GPO rather than the local policy store: add -PolicyStore domain.example.com\GPO_Name to New-NetFirewallRule. For multiple rules against the same GPO, load it once with Open-NetGPO, make all your changes against that session, and commit them together with Save-NetGPO — this avoids hammering the domain controller with one write per rule.

Central Management and Local Policy Merge

In a domain environment, firewall rules and profile settings can be deployed through Computer Configuration > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security in Group Policy, or through the equivalent Firewall configuration service provider (CSP) if the device is managed by Intune or another MDM. By default, rules created locally on a machine — including the automatic ones from application install prompts — merge with the centrally deployed rules rather than being overridden by them.

High-security environments often disable this merging behaviour (AllowLocalPolicyMerge, configurable per profile) so that only centrally managed rules take effect. That decision has a real cost: any application that relies on creating its own local firewall rule during installation will no longer be able to, and every inbound requirement has to be identified, documented, and pushed centrally instead. Local Group Policy settings configured through gpedit.msc or secpol.msc on the device still apply even when local merge is disabled through GPO or MDM — that carve-out is for local administrators who manage the box directly, not for arbitrary applications.

Connection Security Rules and Domain Isolation

Beyond basic allow/block filtering, Windows Firewall can require that traffic be authenticated and optionally encrypted using IPsec before it is permitted at all — configured as connection security rules rather than ordinary firewall rules. The common enterprise use of this is domain isolation: domain-joined machines require Kerberos-authenticated IPsec for inbound connections, which means an unmanaged or non-domain device cannot talk to them even if it is sitting on the same subnet and even if a firewall rule would otherwise allow the port.

# Require Kerberos-authenticated IPsec on inbound domain-profile connections,
# request it (but don't require it) outbound - classic domain isolation shape
$kerbProposal = New-NetIPsecAuthProposal -Machine -Kerberos
$phase1 = New-NetIPsecPhase1AuthSet -DisplayName "Kerberos Machine Auth" -Proposal $kerbProposal
New-NetIPsecRule -DisplayName "Domain Isolation" -Profile Domain -Phase1AuthSet $phase1.Name -InboundSecurity Require -OutboundSecurity Request

In Active Directory: Domain isolation policies like this depend on the same Kerberos infrastructure covered in the Kerberos post — if authentication is already unreliable because of clock skew or SPN problems, layering IPsec authentication requirements on top will surface as connection failures that look like a firewall issue but are not.

Troubleshooting Cheat Sheet

Symptom	Likely Cause	Fix
Works on the office LAN, fails on another network	Active profile switched from Domain/Private to Public, where the required rule isn’t enabled.	Enable the rule (or rule group) on the profile actually in use, or confirm the network’s category is what you expect.
An allow rule seems to be ignored	A broader block rule is overriding it — block always wins over allow regardless of specificity.	`Get-NetFirewallRule -Action Block` and check for overlap; narrow the block rule’s scope.
Application silently stopped working after a policy change	Local policy merge was disabled, removing the local rule the app’s installer had created.	Add an explicit centrally-managed allow rule for the application rather than re-enabling local merge everywhere.
New application never prompted, traffic just blocked	Inbound user notification is disabled, so no automatic allow or block rule was ever created.	Stage an explicit allow rule for the application before rollout — this is the expected managed-fleet pattern, not a bug.
Rule exists but traffic still fails after IPsec was introduced	A connection security rule requires authentication the client cannot complete (Kerberos, cert, or NTLM failure).	Check the underlying authentication path first — Windows Firewall is enforcing the requirement correctly.
Someone stopped the firewall service to “fix” a rule problem	`MpsSvc` was stopped directly instead of disabling the profile.	Start the service again; disable the specific profile if the firewall genuinely needs to be off.

Final Thoughts

Windows Firewall with Advanced Security is easy to dismiss as a background feature until a rule interacts badly with a profile switch or a policy merge setting, and then it looks like a mystery. It isn’t — the precedence rules are small, fixed, and consistent: allow beats the default block, block beats allow, and specificity only matters when nothing explicit conflicts.

Treat rule creation as something you stage deliberately for a managed fleet rather than something you let happen automatically one UAC prompt at a time, and most of the tickets this feature generates stop happening before they start.

Key takeaway: Run Get-NetFirewallProfile to confirm which profile is active and enabled, then Get-NetFirewallRule -Action Block to check for an overriding block rule before assuming an allow rule is broken. Stage required rules centrally via GPO before rollout rather than relying on the automatic prompt-and-create behaviour.

Next in this series

Next, we can cover Task Scheduler — how triggers and actions combine, and the specific pitfalls of running scheduled tasks under service accounts.