Your firewall rule is deployed and the traffic is still blocked: profile scoping, rule merge, and the local rules you did not know were being ignored

You deploy a firewall rule. It arrives. You can see it in the console. The traffic is still blocked. Nothing in the rule looks wrong, no error appears anywhere obvious, and the application owner is asking why IT broke their app.

This is one of the most common false-negative troubleshooting traps in Windows. The rule you are looking at is the intended configuration. What decides whether a packet lives or dies is the effective configuration, and Windows builds that from three network profiles, several separate rule stores, and a per-profile switch that decides whether local rules count at all. This post walks through each of those pieces, then shows you how to read the effective set instead of the intended set.

The problem: the rule exists and the traffic does not

Start with the shape of the failure, because it is always the same shape. Someone needs inbound traffic to reach an application. You write an allow rule, deploy it from Microsoft Intune or Group Policy, and confirm it landed on the device. The application still cannot be reached.

There are only a handful of reasons this happens, and none of them produces an error message.

• The rule is scoped to a profile that is not active. A rule that lists only the Domain profile is invisible on a laptop sitting on a hotel network.
• The rule is in a store that is not being honoured. If local rule merge is off, a rule an installer wrote locally is inert, but still shows as enabled.
• An explicit block rule wins. Block beats allow in Windows Defender Firewall, so one forgotten block rule can quietly cancel a whole allow set.
• The rule is disabled, or was never applied. Windows can refuse a rule it cannot parse and carry on without telling anyone who is looking at the console.

The reason this is hard to debug is that every management surface shows you a different slice of the truth. The Windows Defender Firewall with Advanced Security console shows you the rules in the store you are pointed at. netsh shows you the local store by default. Intune shows you what you asked for. Only one view shows you what the packet will meet, and this post ends with that view.

Why it happens: three profiles, several stores, one merge switch

Profiles: Windows chooses, not you

A profile is a named set of firewall settings and rules that applies to a class of network. Windows Defender Firewall has exactly three, and Microsoft documents how each one is selected.

• Domain. Applied automatically to a device joined to an Active Directory domain when it detects the availability of a domain controller. Microsoft is explicit that this profile cannot be set manually.
• Private. Intended for private networks such as a home network. It can be set manually on an interface by an administrator.
• Public. Designed with higher security in mind for public networks such as hotspots, and it is the default profile for unidentified networks.

Selection is driven by Network Location Awareness (NLA), the Windows component that classifies the network an adapter is attached to. On Microsoft Entra joined devices, where there is no domain controller to detect, the NetworkListManager Policy CSP lets you nominate endpoints that mark a network as the domain network.

The second half of the rule matters more for laptops. Microsoft documents that when a device is connected to multiple networks, the most restrictive profile is applied to all network adapters, with public considered most restrictive, then private, then domain. One tethered phone can therefore move an entire domain-joined machine onto the Public profile, and every Domain-only rule stops being evaluated.

Stores: your rule is one voice in a choir

Windows keeps firewall rules in several places, and the enforced set is the sum of them. The -PolicyStore parameter on the NetSecurity cmdlets is the cleanest way to see the model, because Microsoft documents each store by name.

Rules deployed by an MDM such as Intune arrive through the Firewall CSP into the MDM store, and are observed in the ActiveStore with a source type of MDM, a value that does not appear in Microsoft's documented list for that field, so read it as helpful rather than guaranteed. Group Policy rules appear with the documented source type GroupPolicy. Local rules appear as Local. That single field is what turns "I deployed a rule" into "the device is enforcing my rule".

One more documented behaviour bites people who copy rules between stores. Microsoft notes that a rule Name acts like a filename: during Group Policy processing and policy merge, rules that have the same name but come from multiple stores overwrite one another so that only one exists. A GPO with higher precedence therefore silently replaces the local version of a rule with the same name.

The merge switch: the setting that makes local rules vanish

Now the heart of it. Rule merging policy settings control how rules from different policy sources can be combined, and they are configured per profile. Microsoft's own wording for the firewall half is unambiguous.

Read that carefully. The local rules are not deleted, disabled, or flagged. They are ignored. The console still lists them, still shows a green tick, and the traffic they were written for still dies. This is the single most misdiagnosed firewall condition in managed estates, because the evidence you are looking at is telling you the opposite of the truth.

Microsoft is equally clear about the consequence: "If merging of local policies is disabled, centralized deployment of rules is required for any app that needs inbound connectivity." Turning merge off is a legitimate and often correct hardening choice. It is also a commitment to owning every inbound rule your estate will ever need.

There is a second trap in the Intune wording. In the Windows firewall profile, the setting is presented as Ignore all local firewall rules and its partner as Ignore connection security rules. Setting Ignore to Yes means merge is off. The polarity is inverted relative to the CSP node it drives, so a reviewer skim-reading a policy export can easily conclude the opposite of what the device will do.

Precedence: block beats allow, with one documented exception

Microsoft publishes the precedence rules for both inbound and outbound, and they are short.

1. Explicitly defined allow rules take precedence over the default block setting.
2. Explicit block rules take precedence over any conflicting allow rules.
3. More specific rules take precedence over less specific rules, except where an explicit block rule applies. Microsoft's example: if rule 1 covers an IP address range and rule 2 covers a single IP host address, rule 2 takes precedence.

Outbound rules follow the same behaviours. Critically, Microsoft states that "Windows Firewall doesn't support weighted, administrator-assigned rule ordering". There is no rule number to bump. If a block rule overlaps your allow rule, the only fix is to change one of the two rules.

The documented exception is authenticated bypass. A firewall rule created with -OverrideBlockRules $true and an authentication requirement allows traffic from a specified trusted device or user to override firewall block rules. Microsoft's stated use case is scanning servers that must reach managed devices without opening ports. It is the only sanctioned way to beat a block rule, and it requires IPsec authentication to work.

The engine underneath: what calls what

It helps to know which component is doing the ignoring. The chain, from policy to packet, runs like this.

1. Policy arrives, from Group Policy, the Firewall CSP, or a local write, and lands in a registry store.
2. MpsSvc, the service whose display name is Windows Defender Firewall, reads those stores, applies the merge laws, and produces the effective rule set. Its code is C:\Windows\System32\mpssvc.dll, hosted in a svchost.exe process.
3. MpsSvc hands filters to the Base Filtering Engine. Microsoft describes BFE as "a user-mode service (bfe.dll running in a svchost.exe process) that coordinates the WFP components", whose principal tasks are adding and removing filters, storing filter configuration, and enforcing configuration security.
4. The Windows Filtering Platform filter engine does the work, with a user-mode component that performs RPC and IPsec filtering and a kernel-mode component that filters at the network and transport layers of the TCP/IP stack.
5. Callout drivers plug into the kernel-mode layers. The firewall's own authorization driver is C:\Windows\System32\drivers\mpsdrv.sys.

How to verify: reading the effective rule set

Everything above is background. This section is the actual technique: stop reading the policy you wrote, and read what the device merged.

Step 1: which profile is actually in force

The two cmdlets below answer that. The first reports the network category of each connected interface, which is what NLA decided. The second reports the firewall's own per-profile state as merged into the ActiveStore.

Read the output top to bottom. If NetworkCategory is Public and your rule is Domain-scoped, you have your answer and you can stop. If AllowLocalFirewallRules is False and your rule was created locally, likewise.

Step 2: where did each rule come from

The -TracePolicyStore switch asks Windows to record, for each rule in the ActiveStore, which store it came from. Grouping on that field gives you the policy-versus-local split in one line.

Microsoft explains why that last pair of commands is needed: when you run a Get cmdlet for a rule, common conditions such as addresses and ports do not appear, because they are represented in separate objects called filters, in a one-to-one relationship with the rule. If you never pull the filter, you never see the port your rule actually opened.

Step 3: the registry, one store at a time

Each store is a registry location, and reading them side by side shows you which one is imposing the setting. Group Policy writes under the policies hive; the local and MDM stores live under the SharedAccess service key.

The Group Policy store is a different hive, and its profile subkey names differ from the local store's. Microsoft's protocol documentation for the merge values is precise about this.

That naming split is worth internalising. The private profile is StandardProfile in the local store and PrivateProfile in the Group Policy store. A detection script that assumes one name for both stores will report a clean device that is actually misconfigured.

Step 4: Event Viewer, on two different logs

The firewall writes operational events to its own channel, and the filtering platform writes enforcement events to the Security log. They are separate, and you need both.

Microsoft does not publish a per-ID reference for that channel. The IDs below were observed on a live Windows 11 Enterprise build 26200 device, with their literal message text. Treat them as useful signposts, not as a contract: an undocumented event ID can change in any update, so do not build compliance detection on them.

The Security log is the documented half, and it is where enforcement is proved. Two audit subcategories matter, and neither is on by default.

Events 4957 and 4958 are the ones worth wiring into a SIEM permanently. They are the only place Windows tells you it received a rule and declined to use it.

Turning the audit subcategories on is a Group Policy or Intune job, and it is genuinely per-device policy rather than a firewall setting.

Step 5: the firewall log file

The text log is the fastest way to see individual drops without touching audit policy. It records nothing until you ask it to. The default path is %windir%\system32\logfiles\firewall\pfirewall.log and the default maximum size in the Group Policy dialog is 4,096 KB. Microsoft recommends raising that to at least 20,480 KB, notes the maximum is 32,767 KB, and recommends a separate file per profile.

Read a DROP line right to left. The path column tells you the direction, RECEIVE for inbound and SEND for outbound, and the pid column gives you the process to blame. Addresses in the block above are RFC 5737 documentation addresses standing in for the real ones from a genuine capture.

Step 6: the console's own effective view

The Windows Defender Firewall with Advanced Security snap-in has an often-ignored node that shows the merged set. In Microsoft's own lab walkthrough for disabling local merge, step four is to expand Monitoring and select Firewall to see the list of rules active on the local computer, and the expected result once merge is off is that no local rules are listed. If a rule appears under Inbound Rules but not under Monitoring, it is not being enforced.

The fix: scope it right, then decide about merge

Fixing this is a decision tree, not a single setting. Work through it in order.

1. Confirm the active profile with Get-NetConnectionProfile. If your rule excludes it, widen the rule's scope rather than changing the network category.
2. Confirm the merge state per profile in the ActiveStore. If merge is off by design, the rule must be deployed centrally, full stop.
3. Search for an overlapping block rule, because block beats allow and no ordering can save you.
4. Check 4957 and 4958 to rule out a rule that was received and rejected.

Deploying the rule and the merge settings from Intune

Intune splits this across two profile types: one for per-profile firewall settings, one for the rules themselves.

1. Sign in to the Microsoft Intune admin center.
2. Go to Endpoint security > Firewall > Create policy.
3. Choose platform Windows 10, Windows 11, and Windows Server and profile Windows Firewall, then select Create.
4. Enter a name and an optional description, then select Next.
5. Under Configuration settings, expand each network location type in turn: Domain, Private and Public. Configure all three, even if you only care about one. A device that roams will use whichever you neglected.
6. For each profile, set Turn on Windows Firewall to Yes, then set Block inbound connections and Block outbound connections to match your standard.
7. Decide the merge behaviour with Ignore all local firewall rules and Ignore connection security rules. Remember the inverted wording: Yes means local rules are ignored, which is AllowLocalPolicyMerge set to false.
8. Still per profile, configure Log file path, Enable log dropped packets, Enable log success connections and Log max file size.
9. Select Next twice, assign the policy to a group containing the target devices, then Next and Create.

The rules themselves go in a separate profile, and this is the one to use when merge is off.

1. Create the policy as above, choosing the Windows Firewall Rules profile.
2. Add a rule and give it a Name and Description. The name must not contain a forward slash, which the CSP rejects.
3. Set Direction to In or Out and Action to Allowed or Blocked.
4. Set Network type. Select Domain, Private and Public unless you have a specific reason not to. Leaving the field unselected applies the rule to all network types.
5. Under Application settings, give a File path such as C:\Program Files\Contoso\app.exe, or a Service name short name when a service rather than an application is sending the traffic. Wildcard paths such as C:\*\app.exe are not supported.
6. Under Port and protocol settings, set Protocol to 6 for TCP or 17 for UDP, then the local and remote ports.
7. Under IP address settings, prefer a specific Remote address range, or the token LocalSubnet, over any address.
8. Assign and create.

If you would rather use a custom policy, the CSP nodes are the same ones the built-in profile drives.

The same settings in Group Policy

Group Policy exposes both halves in the same properties dialog, per profile tab. This surface is not CSP-only or GPO-only; both exist and both write the values documented earlier.

1. Open the GPO in the Group Policy Management Editor and expand Computer Configuration > Policies > Windows Settings > Security Settings > Windows Defender Firewall with Advanced Security.
2. In the details pane, in the Overview section, select Windows Defender Firewall Properties.
3. Select the tab for the profile you are configuring: Domain Profile, Private Profile or Public Profile.
4. In the Settings section, select Customize.
5. In the Rule merging section, set Apply local firewall rules to No to stop honouring local firewall rules.
6. In the same section, set Apply local connection security rules to No to stop honouring local IPsec rules.
7. Optionally set Display a notification to No, which suppresses the prompt that otherwise creates rules on the user's behalf.
8. Select OK to return to the profile tab. Under Logging, select Customize.
9. Set the log path, raise the size limit, and set Log dropped packets to Yes. Nothing is logged until you do.
10. Select OK twice, then repeat from step 3 for the other two profiles.

Surfaces that do not apply here

Two items on the usual checklist are genuinely not part of this feature, and saying so is more useful than silence. There is no scheduled task under \Microsoft\Windows\ that drives Windows Defender Firewall; enforcement is entirely the MpsSvc service plus the WFP filter engine, and a search of the task library on a live device returns nothing firewall-related. There is also no separate Defender antivirus or attack-surface-reduction setting involved: the firewall shares the Defender name and the Endpoint security node in Intune, but the profile type you need is Firewall or Windows Firewall Rules, not Antivirus and not Attack surface reduction.

Proof it worked: a real posture report

The companion script for this post reads every surface above and prints one report. It is read-only: no Set, New, Remove, Enable or Disable against any rule, service or registry value. It needs no module, because NetSecurity ships with Windows, and it runs on both Windows PowerShell 5.1 and PowerShell 7.

That output is the whole argument of this post in one screen. The firewall is healthy, the policy applied cleanly, and 395 rules that look perfect in the console are doing nothing. Nobody would find that by reading the rule list.

Two details are worth calling out because they are the failure modes the script is built to catch. First, the merge column shows NotConfigured locally and False effectively, which is how you tell a central override from a local choice. Second, the script exits 1 and says the report would be misleading if any required read fails, rather than printing a clean summary with blank fields.

References

• Windows Firewall overview - the three profiles, how each is selected, default inbound and outbound behaviour, and why not to stop MpsSvc.
• Windows Firewall rules - rule precedence, local policy merge, the local Group Policy exception, and the design recommendations.
• Firewall CSP - every node quoted here, including AllowLocalPolicyMerge, AllowLocalIpsecPolicyMerge, the profile bitmask and the logging nodes.
• Configure Windows Firewall logging - default path, size guidance, the Intune and GPO click paths, and the mpssvc permission fix.
• Manage Windows Firewall with the command line - PowerShell and netsh equivalents, policy stores, filter objects and authenticated bypass.
• Get-NetFirewallRule - the documented -PolicyStore values, -TracePolicyStore, and the note that filter conditions live in separate objects.
• MS-GPFAS: Allow Local Firewall Rule Policy Merge - the exact Group Policy registry keys, value name and data, including the StandardProfile exclusion.
• Audit MPSSVC Rule-Level Policy Change - the 4944 to 4958 event list, including 4957 and 4958 for rules that were not applied.
• Event 5157: The Windows Filtering Platform has blocked a connection and Audit Filtering Platform Packet Drop - field descriptions and the event-volume warnings.
• WFP architecture - the Base Filtering Engine, bfe.dll, the user-mode and kernel-mode filter engine components, and callout drivers.

Community deep-dives, each checked for this post: