Event ID 4953 — Firewall Rule Processing
Applies To: Windows Server 2008
.jpg)
Windows Firewall with Advanced Security receives its rules from local security policy stored in the system registry, and from Group Policy delivered by Active Directory. After receiving a new or modified policy, Windows Firewall must process each rule in the applied policies to interpret what network traffic is to be blocked, allowed, or protected by using Internet Protocol security (IPsec).
When appropriate auditing events are enabled (https://go.microsoft.com/fwlink/?linkid=92666), Windows reports successes and failures, both in retrieving policy and in processing the rules defined in the policy.
Event Details
| Product: | Windows Operating System |
| ID: | 4953 |
| Source: | Microsoft-Windows-Security-Auditing |
| Version: | 6.0 |
| Symbolic Name: | SE_AUDITID_ETW_FIREWALL_RULE_REJECTED |
| Message: | A rule has been ignored by Windows Firewall because it could not parse the rule. %t Profile:%t%1 Reason for Rejection:%t%2 Rule: %tID:%t%3 %tName:%t%4 |
Resolve
Deploy rules only to computers that can process the rules
When you create or edit a Windows Firewall rule, the settings that you can include depend upon the version of Windows you use when creating the rule. As new settings are added to later versions of Windows or to service packs for existing versions of Windows, the version number of the rules processing engine is updated, and that version number is stamped into rules that are created by using that version of Windows. For example, Windows Vista produces firewall rules that are stamped with version "v2.0". Future versions of Windows might use "v2.1", or "v3.0" to indicate, respectively, minor or major changes and additions.
If you create a firewall rule on a newer version of Windows that references firewall settings that are not available on earlier versions of Windows, and then try to deploy that rule to computers running the earlier version of Windows, the firewall engine produces this error to indicate that it cannot process the rule.
The only solution is to remove the incompatible rule, and then deploy a compatible rule.
If you receive this error, you need to review the following and take the appropriate corrective actions:
- If you are supporting multiple versions of Windows and want to deploy only one set of rules to all of them, then create the rule set on a computer running the oldest version of Windows that you support. Later versions of Windows usually support settings introduced in earlier versions. You must still test the policies for compatibility with all versions of Windows to which you want to deploy them, because sometimes an older setting is no longer implemented in newer versions of Windows. For example, you might have to support computers running a version of Windows that can support firewall rules stamped v2.0, and a later version of Windows that supports both v2.1 and v2.0. If you create all such rule sets on a computer running the earlier version of Windows to ensure they are stamped with v2.0, then those rule sets are probably compatible with all of the computers you support.
- If the range of Windows versions that you need to support do not have a common firewall rules engine version number that they can all process, then you need to deploy a set of rules separately to each group. For example, if one set of computers is running a version of Windows that supports only v2.0 firewall rules, and another set of computers is running a version of Windows that supports only a minimum of version v3.0 firewall rules, then you must create both v2.0 and a v3.0 rule sets, and ensure that each rule set is deployed to only the computers with the appropriate version of Windows. Windows Management Instrumentation (WMI) filters can be used with Group Policy to specify criteria such as operating system version number to which the Group Policy object is to apply. For more information about using WMI filters with Group Policy, see "WMI filtering using GPMC" at https://go.microsoft.com/fwlink/?linkid=93188.
Verify
You can verify that your computer is successfully retrieving and processing firewall and Internet Protocol security (IPsec) settings and rules by examining the Event Viewer logs and looking for messages that indicate successful firewall policy processing. To ensure that your computer is creating the appropriate events as required, see https://go.microsoft.com/fwlink/?linkid=92666.
To verify that firewall policy is being retrieved and processed correctly:
- Refresh Group Policy. Open an administrative command prompt. Click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator. At that command prompt, run the command gpupdate /force.
- After the policy refresh is complete, examine the Event log for the following event IDs:
- 4945-4948. These messages indicate successful processing of locally stored firewall policy.
- 4954-4955. This message indicates successful processing of Group Policy-provided firewall policy.
- 5040-5049. These messages indicate successful processing of IPsec policy.
The presence of one or more of those event messages when a changed policy is received is an indication that policy is being received and processed correctly.
You can also change a rule (in locally stored policy or a Group Policy object), and then examine the rules on the computer to confirm that the changed rule was received and processed correctly. Use the Windows Firewall with Advanced Security Microsoft Management Console (MMC) snap-in or the netsh advfirewall command-line tool to examine the rules on the local computer. The exact branch in the snap-in or the netsh command to use depends on the rule that you want to change.