From f67d9d52480b0ab60c5f7d971786f4622c769e45 Mon Sep 17 00:00:00 2001 From: Benny Shilpa Date: Fri, 20 Nov 2020 15:19:42 +0530 Subject: [PATCH] Update filter-origin-documentation.md --- .../filter-origin-documentation.md | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/windows/security/threat-protection/windows-firewall/filter-origin-documentation.md b/windows/security/threat-protection/windows-firewall/filter-origin-documentation.md index b87dd45928..9f32d988b7 100644 --- a/windows/security/threat-protection/windows-firewall/filter-origin-documentation.md +++ b/windows/security/threat-protection/windows-firewall/filter-origin-documentation.md @@ -19,11 +19,11 @@ ms.topic: troubleshooting Debugging packet drops is a continuous issue to Windows customers. In the past, customers had limited information about packet drops. -Typically, when investigating packet drop events, a customer would use the field `Filter Run-Time ID` from WFP Audits 5157 or 5152. +Typically, when investigating packet drop events, a customer would use the field `Filter Run-Time ID` from Windows Filtering Platform (WFP) Audits 5157 or 5152. ![Event Properties](images/event-properties-5157.png) -The filter ID uniquely identifies the filter that caused the packet drop. The filter ID can be searched in the WFP state dump output to trace back to the FW rule where the filter originated from. +The filter ID uniquely identifies the filter that caused the packet drop. The filter ID can be searched in the WFP state dump output to trace back to the Firewall rule where the filter originated from. However, the filter ID is not a reliable source for tracing back to the filter or the rule, as the filter ID can change for many reasons despite the rule not changing at all. This makes the diagnosis process error-prone and difficult. @@ -55,7 +55,7 @@ The next section describes the improvements made to Audits 5157 and 5152 and how The two new fields added to the Audit 5157 and 5152 events are `Filter Origin` and `Interface Index`. -The `Filter Origin` field will help identify the cause of the drop. Packet drops from FW are explicitly dropped by default block filters created by the Windows Firewall service or a FW rule which may be created by users, policies, services, apps, etc. +The `Filter Origin` field will help identify the cause of the drop. Packet drops from Firewall are explicitly dropped by default block filters created by the Windows Firewall service or a Firewall rule which may be created by users, policies, services, apps, etc. `Filter Origin` will either specify the rule ID (a unique identifier of a Firewall rule) or the name of one of the default block filters. @@ -96,7 +96,7 @@ After identifying the rule that caused the drop, the network admin can now modif **AppContainer Loopback** -Network drop events from the AppContainer Loopback block filter origin occur when localhost loopback is not enabled properly for the UWP app. +Network drop events from the AppContainer Loopback block filter origin occur when localhost loopback is not enabled properly for the Universal Windows Platform (UWP) app. To enable localhost loopback in a local debugging environment, see [Communicating with localhost](https://docs.microsoft.com/windows/iot-core/develop-your-app/loopback). @@ -128,9 +128,9 @@ To learn more about the quarantine feature, see [Quarantine Behavior](quarantine Network packet drops from Query User Default block filters occur when there is no explicit rule created to allow an inbound connection for the packet. When an application binds to a socket but does not have a corresponding inbound rule to allow packets on that port, Windows generates a pop up for the user to allow or deny the app to receive packets on the available network categories. If the user clicks to deny the connection in this popup, subsequent inbound packets to the app will be dropped. To resolve the drops: -1. Create an inbound FW rule to allow the packet for this application. This will allow the packet to bypass any Query User Default block filters. +1. Create an inbound Firewall rule to allow the packet for this application. This will allow the packet to bypass any Query User Default block filters. -2. Delete any block Query User rules which may have been auto generated by the FW service. +2. Delete any block Query User rules which may have been auto generated by the Firewall service. To generate a list of all the Query User block rules, you can run the following PowerShell command: @@ -161,11 +161,11 @@ To disable Stealth-mode, see [Disable stealth mode in Windows](https://docs.micr **UWP Default** -Network drops from UWP Default Inbound/Outbound block filters are often caused by the UWP app not being configured correctly (i.e. the UWP app is missing the correct capability tokens or loopback is not enabled) or the private range is configured incorrectly. +Network drops from Universal Windows Platform (UWP) Default Inbound/Outbound block filters are often caused by the UWP app not being configured correctly (i.e. the UWP app is missing the correct capability tokens or loopback is not enabled) or the private range is configured incorrectly. For more information on how to debug drops caused by UWP default block filters, see [Troubleshooting UWP App Connectivity Issues](https://docs.microsoft.com/windows/security/threat-protection/windows-firewall/troubleshooting-uwp-firewall). **WSH Default** -Network drops from WSH default filters indicate that there wasn’t an explicit Windows Service Hardening allow rule to allow network traffic for the protected service. The service owner will need to configure allow rules for the service if the block is not expected. +Network drops from Windows Service Hardening (WSH) default filters indicate that there wasn’t an explicit Windows Service Hardening allow rule to allow network traffic for the protected service. The service owner will need to configure allow rules for the service if the block is not expected.