Find Windows Firewall rules blocking traffic
Windows Firewall is great for protecting both Windows servers and clients alike, and is generally enabled as a best practice. But what if traffic is being blocked by the firewall and you aren’t sure exactly why?
In this post I’ll be going over how to identify specific firewall rules responsible for blocking traffic.
1.0 Introduction
1.1 The Problem
Out of the box Windows doesn’t log connection attempts that are blocked by the Windows Firewall.
Diagnosing network connectivity issues, unavailable services, etc. can therefore becoming a bit tricky.
1.2 The Solution
The solution is to enable verbose logging with the Windows Filtering Platform. As traffic is blocked an event will be recorded in the Windows Security Event Log.
In this post I’ll show you how to:
- Enable Windows Filtering Platform (WFP) Auditing
- Export Windows Firewall rules to XML
- Find blocked traffic events in Windows Event Viewer
- Match ‘filterID’ to a firewall rule
2.0 Enable WFP Auditing
Open a PowerShell prompt as administrator and run the following two commands:
|
|
This has now enabled verbose logging. If traffic is blocked by the Windows Firewall an event will be recorded in the Windows Security Event Log.
3.0 Export rules to XML
From a PowerShell prompt (as administrator) run the following command:
|
|
This will output a file called ‘wfpstate.xml’ into the directory where the command was run.
For example, the screenshot below shows the command being run from C:\Users\Administrator.
This causes the file to be created at C:\Users\Administrator\wfpstate.xml.
wfpstate.xml in C:\Users\Administrator
4.0 Check Event Logs
Open Windows Event Viewer and Browse to Windows Logs > Security.
The two events we’re looking for are:
- Event ID 5157 “Filtering Platform Connection”
- Event ID 5152 “Filtering Platform Packet Drop”
Any of these events corresponds to a Windows Firewall connection or packet drop.
Here’s an example of some events:
Connection or packet drop events
Open an event and find the ‘Filter Run-Time ID’ under ‘Filter Information’.
Culprit found: Filter Run-Time ID 68338
Make a note of the Filter Run-Time ID. This is the ID number of the firewall responsible for blocking traffic.
5.0 Match ‘Filter ID’ to Firewall Rules
Open the previously created wfpstate.xml file in a text editor (i.e. notepad).
Run a search (Ctrl+F) for the filter ID number.
Once found, scroll up to the first set of name tags. This is the name of the offending firewall rule.
Here’s an example:
Filter ID '68338' corresonds to 'Block port 445'
Now armed with the name of a firewall rule, we can find it within the Windows Firewall app:
There are a few ‘special’ firewall rules.
These include:
- Port Scanning Prevention Filter
This rule blocks traffic when no service is listening on a port. I.e. if no service is listening on port ‘80’ the firewall will block all traffic to port 80. - Query User
This rule is designed to show a Windows Firewall Block/Allow prompt to the user under certain conditions.
These firewall rules can’t be seen within the Windows Firewall app.
6.0 Troubleshooting Group Policy
When troubleshooting firewall rules, check to see if any rules are applied by group policy.
Group policy makes it is possible to disable local firewall rule processing.
This can cause some confusion as the Windows Firewall app will still allow you to create, view and edit firewall rules. However, none of these rules will actually be applied.
Check the ‘Apply loal firewall rules’ setting on both the local computer and group policy settings.
7.0 Closing Thoughts
The Windows Firewall, whilst quite powerful, doesn’t have the best user interface. I hope this article was of some use to you.
If you have any questions or a tip I’ve missed, please do get in touch via the comments section below.
Comments