The Windows Defender Firewall is not one rule set but three, called profiles, and Windows automatically applies the one that matches the network a given interface is attached to. The same machine can have different rules active depending on where it is plugged in.

The three profiles. Domain applies when the interface can reach an Active Directory domain controller. Private applies on networks you have marked as trusted (home or office). Public applies on everything else and is the most restrictive. All three default to allowing outbound traffic and blocking unsolicited inbound.

Why it matters. A rule scoped to the Domain profile simply does not apply when the interface is classified as Public, which is the root cause of a huge share of "the rule exists but traffic is still blocked" tickets. Know which profile is active before you debug a rule.

Firewall rules come in two directions, and the default posture of each is the opposite of the other, which is the first thing to internalize.

Inbound traffic is blocked by default: unsolicited connections from outside are dropped unless a rule explicitly allows them. This is why standing up a new service almost always requires adding an inbound allow rule. Outbound traffic is allowed by default: the server can reach out freely. Tightening outbound (blocking it by default and allowing only what is needed) is a hardening step that limits malware's ability to exfiltrate or call home.

How rules match. Each rule filters on one or more criteria: a specific program, a port or port range, a predefined Windows service group, or a fully custom combination of address, port, and protocol. The more specific the match, the tighter the rule.

Creating a rule in PowerShell with New-NetFirewallRule is the precise, repeatable alternative to clicking through the GUI, and it is how rules get scripted into deployments.

The anatomy of a rule. You give it a display name, a direction (inbound/outbound), a protocol and local port, an action (allow/block), and ideally a scope, the profiles it applies to and the remote addresses it accepts. Every parameter you add narrows the rule and shrinks the attack surface.

Scope tightly. An inbound web rule that allows 80 and 443 on the Domain and Private profiles is good; an RDP rule that allows 3389 only from your admin subnet is far better than one open to everyone. Restricting the remote address is the single most effective tightening you can apply.

Beyond the basics, firewall rules support fine-grained properties that let you constrain exactly who and what a rule applies to. Used well, they turn a broad "allow this port" into a tightly scoped exception.

The high-value properties. LocalAddress / RemoteAddress restrict the rule to specific subnets or keywords like LocalSubnet. LocalPort / RemotePort pin the rule to exact ports or ranges. LocalUser / RemoteUser can require that the connection belong to a specific authenticated user or group (which depends on IPsec authentication being in place).

The pattern that matters. Combining a port with a remote-address restriction is the standard way to expose management interfaces (WinRM on 5985/5986, RDP on 3389) to administrators only, rather than to the whole network.

A firewall is only as good as your understanding of what it currently permits. Auditing the live rule set is a routine you run before and after any change.

See the full picture. Listing every enabled inbound rule with its profile and action tells you exactly what traffic the server accepts right now, which is the starting point for both hardening and troubleshooting. Rules accumulate over a server's life, and stale allow rules are a real risk.

Find rules fast. When you need a specific rule, searching by a display-name pattern (for example everything matching *RDP*) narrows hundreds of rules to the handful you care about, so you can inspect or change the right one.

Once you can find a rule, the lifecycle operations are inspect, disable, modify, and delete, each a distinct cmdlet so changes are explicit and scriptable.

Inspect the details. A rule's port and address details live in separate filter objects; piping a rule to Get-NetFirewallPortFilter reveals exactly which ports it governs, which the rule listing alone does not show.

Change safely. Prefer Disable-NetFirewallRule over deletion when troubleshooting, it is reversible. Use Set-NetFirewallRule to tighten an existing rule (for example narrowing its remote address) and Remove-NetFirewallRule only for rules you are certain are obsolete. Disabling first, confirming, then removing is the safe order.

Firewall rules decide whether traffic is allowed; connection security rules decide whether traffic is authenticated and encrypted. They implement IPsec, and together with firewall rules they enable domain and server isolation.

Authentication methods. A connection security rule can require the two endpoints to prove identity via Kerberos (the domain default), computer or user certificates, a pre-shared key (testing only), or NTLMv2. Once authenticated, the traffic can also be encrypted.

The rule types. Isolation requires authentication for connections matching a policy; Exemption excludes specific hosts (like DCs) from that requirement; Server-to-server secures a named pair of endpoints; Tunnel secures gateway-to-gateway traffic. Domain isolation, where only authenticated domain members can connect, is the flagship use.

By default the firewall logs very little, which makes "why was this dropped?" hard to answer. Turning on logging is the prerequisite for evidence-based firewall troubleshooting.

What you can log. Per profile, you control whether blocked connections are logged, whether allowed connections are logged, the maximum log file size, and the log file path (the default lives under the Windows Firewall directory). Logging blocked packets is the most useful setting for diagnosing connectivity failures.

Operational note. Logging is per-profile, so enable it on the profile that is actually active (usually Domain on a server). Cap the file size so logs rotate rather than filling the disk, and remember that logging allowed traffic on a busy server produces a lot of volume.

Managing firewall rules box by box does not scale. Group Policy lets you author firewall configuration once and enforce it across every server in an OU, with the GPO winning over local settings.

Where the settings live. In the GPO under Computer Configuration, Policies, Windows Settings, Security Settings, Windows Defender Firewall with Advanced Security. There you define inbound/outbound rules and connection security rules exactly as you would locally, but they apply to every targeted machine.

The key decision: merge or replace. You choose, per profile, whether locally created firewall rules and connection security rules are merged with the GPO rules or ignored entirely. Ignoring local rules gives central control and predictability; allowing merge gives flexibility but lets local admins poke holes. You also set default inbound/outbound actions and logging centrally.

Configuring a firewall well means knowing which ports a Windows server legitimately needs, so you open exactly those and no more. These are the workhorses you will see constantly.

The core set. DNS on TCP/UDP 53 for name resolution; Kerberos on TCP/UDP 88 for authentication; LDAP on 389 (and secure LDAPS on 636) for directory queries; SMB on TCP 445 for file sharing and much of the domain's internal plumbing. A domain controller needs most of these open to its clients and peers.

The one to never get wrong. RDP (3389) must never be exposed directly to the internet, it is a constant target for brute force and exploits. Put remote access behind a VPN or a Remote Desktop Gateway, and restrict 3389 to admin subnets even internally.

Firewall troubleshooting goes fastest when you ask three questions in order rather than guessing. Each answer narrows the cause.

1. Is it the firewall at all? Temporarily disable the active profile and retest. If traffic now flows, the firewall is the cause; if not, look elsewhere (routing, the service itself). Re-enable immediately after the test.

2. Which rule? Enable blocked-connection logging, reproduce the failure, and read the log to see exactly what was dropped and which rule (or absence of a rule) caused it.

3. Which profile? Run Get-NetConnectionProfile. A rule scoped to Domain does nothing if the interface is classified as Public, an extremely common and easily missed cause. Fixing the network category often fixes the "broken" rule.

Two commands answer the bulk of firewall connectivity questions: one shows what the firewall is actively dropping, the other tests whether a path is open end to end.

Find active blocks. Filtering the inbound rules down to those that are both enabled and set to Block reveals exactly what the firewall is explicitly dropping. An unexpected block rule, or a broad one shadowing your allow, is a frequent culprit.

Test the path. Test-NetConnection -Port attempts a real TCP connection to a host and port and reports success or failure, distinguishing "the firewall blocks it" from "the service is not listening" or "the route is down." It is the first thing to run when a client cannot reach a service.

When the first pass does not explain a failure, you correlate ports to rules and read the firewall's own event log for the authoritative record.

Map a port to its rule. Piping enabled inbound rules through Get-NetFirewallPortFilter and filtering to a specific local port (say 443) tells you precisely which rule governs that port, useful when several rules overlap and you need to know which one is in effect.

Read the event log. The Windows Firewall operational log records rule changes and significant events; pulling the recent entries with Get-WinEvent surfaces things like a rule that was modified or a profile that switched. The usual root causes are a missing inbound rule, a GPO that has not applied yet, or the wrong active profile.

The labs take firewall management from reading commands to running them, configuring protection and then proving it behaves as intended.

In the GUI lab you set profile behavior, create inbound rules and port exceptions, and turn on logging, the click-path equivalent of the cmdlets in this module.

In the PowerShell lab you drive Set-NetFirewallProfile and New-NetFirewallRule, query the live rule set, enable logging, and test connectivity, the scriptable approach that scales across servers and into GPOs.