Horizon Connectivity: Auditing Effective Windows Firewall Policy
- Get link
- X
- Other Apps
An allowed application can still be blocked by the effective Windows Firewall configuration. This focused guide audits policy before a Horizon firewall change. It is not evidence that the firewall causes every “Agent Unreachable” event.
Correction, September 12, 2026: The previous version implied that unchecking one option or rebooting would usually resolve the issue. The current workflow requires a matching policy/traffic finding and authorization from the security-policy owner.
Distinguish default blocking from blocking all inbound connections
Microsoft describes the “Block all incoming connections” option as ignoring the allowed-app list. This is different from ordinary default inbound blocking with permitted exceptions. Do not weaken an intentional security baseline simply because an application has a connectivity problem.
Collect the effective state
The following read-only PowerShell query lists profile settings. Run it in the approved administrative context; determine which profile applies to the affected interface rather than treating all returned profiles as active:
Get-NetFirewallProfile -PolicyStore ActiveStore |
Select-Object Name, Enabled, DefaultInboundAction, AllowInboundRules, AllowLocalFirewallRules
See Microsoft's Get-NetFirewallProfile reference. Also record the matching rule's enabled state, direction, program/service, transport, addresses, and policy origin. Domain policy can prevent a locally created exception from having the effect you expect.
| Finding | Interpretation | Action |
|---|---|---|
| Rule exists but is scoped to another profile/address | Existence is not evidence of a match. | Compare the actual flow and effective scope. |
| Inbound exceptions are ignored | A profile-level restriction may override the intended exception. | Ask the security owner whether a scoped baseline adjustment is permitted. |
| Settings revert after policy refresh | A central policy may own the setting. | Correct the authoritative policy, not a recurring local workaround. |
| No matching deny or policy conflict | The firewall hypothesis is not established. | Return to Agent and connection-stage evidence. |
Validate a specific flow
Match source component, destination component, transport, port, and timestamp with the Horizon network design. Log collection settings affect what evidence is available; the absence of a log entry is not proof of an allow. Keep captures and internal addressing out of public comments.
Change, verify, restore
With policy-owner approval, test only the necessary rule or profile correction on one desktop. Preserve the original policy and ensure the management path remains available. Keep the firewall enabled. Do not add broad antivirus/EDR exclusions as a substitute for diagnosis.
Repeat the original failure, fresh login, and reconnect. Confirm effective policy again after its normal refresh and ensure unrelated inbound access has not broadened. Restore the prior approved configuration if the correction fails or creates an exposure. Microsoft's firewall rule configuration guidance is the implementation reference, not a blanket exemption for Horizon traffic.
Related troubleshooting guides
- Get link
- X
- Other Apps
Comments
Post a Comment