Network Profile Mismatch Leading to Unintended Public Access

Direct Answer

Windows 11 enforces the Public network profile primarily through Windows Firewall with Advanced Security (WFAS), which maintains three independent, profile-scoped rule sets (Domain, Private, Public). The Network Location Awareness (NLA) service classifies each network interface; when the classification changes, the Windows Firewall service (MpsSvc) instantly activates the corresponding rule set — no service restart, no manual rule editing required. The Public profile restricts inbound traffic by simply omitting allow rules for file/printer sharing, RDP, and network discovery that exist in the Private and Domain profiles. Built-in rules switch automatically; custom or third-party rules must explicitly declare their Profile scope (Domain, Private, Public, or Any) to behave correctly across changes.

Mechanism Beyond Service Disabling

The enforcement is not merely disabling services (e.g., FDResPub, SSDPSRV). Instead:

• Profile-aware rule evaluation: Every inbound/outbound firewall rule carries a Profile property. Only rules matching the active profile on a given interface are evaluated.
• Default deny posture: The Public profile ships with DefaultInboundAction = Block and no built-in allow rules for SMB (TCP 445), RDP (TCP 3389), LLDP/SSDP discovery, or Print Sharing. Equivalent allow rules exist only in Private/Domain profiles.
• Rule groups tied to profiles: The "Network Discovery" and "File and Printer Sharing" rule groups are enabled only for Private/Domain. Toggling the profile in Settings flips these groups on/off via the firewall, not via service control.

Automatic Adaptation vs. Manual Verification

Built-in rules adapt automatically. When NLA reclassifies an interface (e.g., after joining a domain, changing DNS suffix, or user action in Settings), MpsSvc switches the active rule set within seconds. You do not need to manually verify inbound rules after a legitimate profile change.

Manual verification is necessary when:

1. You have created custom firewall rules without an explicit -Profile parameter (they default to Any and apply everywhere, potentially bypassing Public restrictions).
2. A third-party endpoint agent manages its own firewall and may not honor Windows profile changes.
3. Group Policy or MDM locks the profile assignment or firewall configuration, preventing automatic switching.

Verification Steps (Run Once to Confirm)

# 1. Confirm current profile per interface
Get-NetConnectionProfile

# 2. Inspect active Public-profile rules
Get-NetFirewallRule -PolicyStoreSource ActiveStore -Profile Public |
  Where-Object {$_.Enabled -eq 'True'} |
  Select-Object DisplayName, Name, Action, Direction, LocalPort, Profile

# 3. Verify default inbound action for Public
Get-NetFirewallProfile -Name Public | Format-List DefaultInboundAction, DefaultOutboundAction

# 4. Functional test: SMB inbound from another host on same subnet
Test-NetConnection -ComputerName <local-ip> -Port 445

One Diagnostic Detail Needed

Are you observing this behavior on a physical adapter, a Hyper-V virtual switch, or a VPN adapter? Each interface is classified independently, and the firewall applies the most restrictive active profile for inbound traffic across all interfaces. The answer changes whether you check one profile or the aggregate effective policy.