From cef561ea53b63153a87c18d7bb65c9810df0cc74 Mon Sep 17 00:00:00 2001 From: Daniel Simpson Date: Thu, 13 Aug 2020 16:23:35 -0700 Subject: [PATCH] more fixin --- .../troubleshooting-uwp-firewall.md | 210 +++++++++--------- 1 file changed, 100 insertions(+), 110 deletions(-) diff --git a/windows/security/threat-protection/windows-firewall/troubleshooting-uwp-firewall.md b/windows/security/threat-protection/windows-firewall/troubleshooting-uwp-firewall.md index fc7c29c60d..bc17fd0a75 100644 --- a/windows/security/threat-protection/windows-firewall/troubleshooting-uwp-firewall.md +++ b/windows/security/threat-protection/windows-firewall/troubleshooting-uwp-firewall.md @@ -19,174 +19,164 @@ ms.topic: troubleshooting This document is intended to help network admins, support engineers, and developers to investigate UWP app network connectivity issues. -# Introduction +This document guides you through steps to debug Universal Windows Platform (UWP) app network connectivity issues by providing practical examples. -This document guides you through steps to debug different Universal Windows Platform (UWP) app network connectivity issues by providing practical case examples. +## Typical causes of connectivity issues -UWP app network connectivity issues typically stem from one of the following causes: +UWP app network connectivity issues are typically caused by: -1. The UWP app was not permitted to receive loopback traffic (this must be configured as, by default, a UWP app is not allowed to receive loopback traffic). +1. The UWP app was not permitted to receive loopback traffic. This must be configured. By default, UWP apps are not allowed to receive loopback traffic. 2. The UWP app is missing the proper capability tokens. -3. The private range is configured incorrectly (i.e. set incorrectly through GP/MDM policies, etc.) +3. The private range is configured incorrectly. For example, the private ranges is set incorrectly through GP/MDM policies, etc. -To understand these causes more thoroughly, there are several concepts that should be reviewed. +To understand these causes more thoroughly, there are several concepts to review. -The traffic of network packets (e.g. what's permitted and what’s not) on Windows is ultimately determined by the Windows Filtering Platform (WFP). When a UWP app +The traffic of network packets (what's permitted and what’s not) on Windows is determined by the Windows Filtering Platform (WFP). When a UWP app or the private range is configured incorrectly, it affects how the UWP app’s network traffic will be processed by WFP. -When a packet is processed by WFP, the characteristics of that packet must explicitly match all the conditions of a filter to either be permitted or dropped to its target address. Connectivity issues typically happen when the packet does not match the filter conditions of any filters, leading the packet to be dropped by a default block filter. The presence of the default block -filters ensures network isolation for UWP applications. Specifically, it guarantees a network drop for a packet that does not have the correct capabilities for the resource it is trying to reach, ensuring the application’s granular access to each resource type and preventing the application from “escaping” its environment. +When a packet is processed by WFP, the characteristics of that packet must explicitly match all the conditions of a filter to either be permitted or dropped to its target address. Connectivity issues typically happen when the packet does not match any of the filter conditions, leading the packet to be dropped by a default block filter. The presence of the default block +filters ensures network isolation for UWP applications. Specifically, it guarantees a network drop for a packet that does not have the correct capabilities for the resource it is trying to reach. This ensures the application’s granular access to each resource type and preventing the application from escaping its environment. For more information on the filter arbitration algorithm and network isolation, -please read [Filter +see [Filter Arbitration](https://docs.microsoft.com/en-us/windows/win32/fwp/filter-arbitration) and [Isolation](https://docs.microsoft.com/en-us/windows/win32/secauthz/appcontainer-isolation). -The next sections will cover debugging case examples for loopback and -non-loopback UWP app network connectivity issues. +The following sections cover debugging case examples for loopback and non-loopback UWP app network connectivity issues. > [!NOTE] -> As improvements to debugging and diagnostics around the Windows Filtering Platform are made, the trace examples in this document may not exactly match the -traces collected on an older Windows build. +> As improvements to debugging and diagnostics in the Windows Filtering Platform are made, the trace examples in this document may not exactly match the +traces collected on previous releases of Windows. # Debugging UWP App Loopback scenarios -If you have a scenario where you are establishing a TCP/IP connection between two processes on the same host where one of them is a UWP app, you must enable loopback. +If you need to establis a TCP/IP connection between two processes on the same host where one of them is a UWP app, you must enable loopback. -To enable loopback for client outbound connections, run the following in a command prompt: +To enable loopback for client outbound connections, run the following at a command prompt: -`CheckNetIsolation.exe LoopbackExempt -a -n=\` +```dos +CheckNetIsolation.exe LoopbackExempt -a -n=\ +``` -To enable loopback for server inbound connections, please run the following in a +To enable loopback for server inbound connections, run the following at a command prompt: +```dos +CheckNetIsolation.exe LoopbackExempt -is -n=\ +``` +You can ensure loopback is enabled by checking the appx manifests of both the sender and receiver. -`CheckNetIsolation.exe LoopbackExempt -is -n=\` - -You can ensure loopback is enabled by checking the appx manifests of both the -sender and receiver. - -For more information about loopback scenarios, please read [Communicating with +For more information about loopback scenarios, see [Communicating with localhost (loopback)](https://docs.microsoft.com/en-us/windows/iot-core/develop-your-app/loopback) # Debugging Live Drops -If the issue happened recently, but you find you are not able to reproduce the -issue, go to Debugging Past Drops for the appropriate trace commands. +If the issue happened recently, but you find you are not able to reproduce the issue, go to Debugging Past Drops for the appropriate trace commands. -If you can consistently reproduce the issue, then you can run the following in -an admin command prompt to gather a fresh trace: +If you can consistently reproduce the issue, then you can run the following in an admin command prompt to gather a fresh trace: -``` +```DOS Netsh wfp capture start keywords=19 \ Netsh wfp capture stop ``` -The above commands will generate a wfpdiag.cab. Inside the .cab exists a -wfpdiag.xml, which contains any allow or drop netEvents and filters that existed -during that repro. Without “keywords=19”, the trace will only collect drop -netEvents. +These commands generate a wfpdiag.cab. Inside the .cab exists a wfpdiag.xml, which contains any allow or drop netEvents and filters that existed during that repro. Without “keywords=19”, the trace will only collect drop netEvents. Inside the wfpdiag.xml, search for netEvents which have -FWPM_NET_EVENT_TYPE_CLASSIFY_DROP as the netEvent type. To find the relevant -drop events, search for the drop events with matching destination IP address, +FWPM_NET_EVENT_TYPE_CLASSIFY_DROP as the netEvent type. To find the relevant drop events, search for the drop events with matching destination IP address, package SID, or application ID name. The characters in the application ID name will be separated by periods: -``` + +```XML (ex) -\ - + \\.d.e.v.i.c.e.\\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.1.\\.w.i.n.d.o.w.s.\\.s.y.s.t.e.m.3.2.\\.s.v.c.h.o.s.t...e.x.e... \ ``` -The netEvent will have more information about the packet that was dropped -including information about its capabilities, the filter that dropped the -packet, and much more. + +The netEvent will have more information about the packet that was dropped including information about its capabilities, the filter that dropped the packet, and much more. ## Case 1: UWP app connects to Internet target address with all capabilities In this example, the UWP app successfully connects to bing.com [2620:1ec:c11::200]. -A packet from a UWP app needs the correct networking capability token for the -resource it is trying to reach. +A packet from a UWP app needs the correct networking capability token for the resource it is trying to reach. -In this scenario, the app could successfully send a packet to the Internet -target because it had an Internet capability token. +In this scenario, the app could successfully send a packet to the Internet target because it had an Internet capability token. -The following shows the allow netEvent of the app connecting to the target IP. -The netEvent contains information about the packet including its local address, +The following shows the allow netEvent of the app connecting to the target IP. The netEvent contains information about the packet including its local address, remote address, capabilities, etc. **Classify Allow netEvent, Wfpdiag-Case-1.xml** ```xml -\ -\ -> \2020-05-21T17:25:59.070Z\ -> \ -> \FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET\ -> \FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET\ -> \FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET\ -> \FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET\ -> \FWPM_NET_EVENT_FLAG_REMOTE_PORT_SET\ -> \FWPM_NET_EVENT_FLAG_APP_ID_SET\ -> \FWPM_NET_EVENT_FLAG_USER_ID_SET\ -> \FWPM_NET_EVENT_FLAG_IP_VERSION_SET\ -> \FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET\ -> \ -> \FWP_IP_VERSION_V6\ -> \6\ -> \2001:4898:30:3:256c:e5ba:12f3:beb1\ \2620:1ec:c11::200\ -\52127\ -\443\ -\0\ -\ -> \5c006400650076006900630065005c0068006100720064006400690073006b0076006f006c0075006d00650031005c00700072006f006700720061006d002000660069006c00650073005c00770069006e0064006f007700730061007000700073005c00610066003600390032006200660066002d0036003700370039002d0034003200340066002d0038003700300065002d006600360065003500390063003500300032003300340039005f0031002e0031002e00310030002e0030005f007800360034005f005f00350063003000330037006a0061007200350038003300390072005c0075007700700073006f0063006b006500740063006c00690065006e0074002e006500780065000000\ -> \\\.d.e.v.i.c.e.\\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.1.\\.p.r.o.g.r.a.m. -> .f.i.l.e.s.\\.w.i.n.d.o.w.s.a.p.p.s.\\.a.f.6.9.2.b.f.f.-.6.7.7.9.-.4.2.4.f.-.8.7.0.e.-.f.6.e.5.9.c.5.0.2.3.4.9._.1...1...1.0...0._.x.6.4._._.5.c.0.3.7.j.a.r.5.8.3.9.r.\\.u.w.p.s.o.c.k.e.t.c.l.i.e.n.t...e.x.e...\ -\ -\S-1-5-21-2993214446-1947230185-131795049-1000\ -\FWP_AF_INET6\ -\S-1-15-2-4163697451-3176919390-1155390458-2883473650-3020241727-522149888-4067122936\ -\ -\0\ -\ -\ -\FWPM_NET_EVENT_TYPE_CLASSIFY_ALLOW\ -\ -> \125918\ -> \50\ -> \0\ -> \1\ -> \1\ -\ -\ -\ -\0000000000000000\ -\ -> \FWP_CAPABILITIES_FLAG_INTERNET_CLIENT\ \FWP_CAPABILITIES_FLAG_INTERNET_CLIENT_SERVER\ -> \FWP_CAPABILITIES_FLAG_PRIVATE_NETWORK\ -\ -\0\ -\ -\ -> \ - \125918\ -> \FWPP_SUBLAYER_INTERNAL_FIREWALL_WSH\ - \FWP_ACTION_PERMIT\ -> \ -> \ - \121167\ - \FWPP_SUBLAYER_INTERNAL_FIREWALL_WF\ - \FWP_ACTION_PERMIT\ - \ -\ -\ -\ + + + 2020-05-21T17:25:59.070Z\ + + FWPM_NET_EVENT_FLAG_IP_PROTOCOL_SET\ + FWPM_NET_EVENT_FLAG_LOCAL_ADDR_SET\ + FWPM_NET_EVENT_FLAG_REMOTE_ADDR_SET\ + FWPM_NET_EVENT_FLAG_LOCAL_PORT_SET\ + FWPM_NET_EVENT_FLAG_REMOTE_PORT_SET\ + FWPM_NET_EVENT_FLAG_APP_ID_SET\ + FWPM_NET_EVENT_FLAG_USER_ID_SET\ + FWPM_NET_EVENT_FLAG_IP_VERSION_SET\ + FWPM_NET_EVENT_FLAG_PACKAGE_ID_SET\ + + FWP_IP_VERSION_V6\ + 6\ + 2001:4898:30:3:256c:e5ba:12f3:beb1\ \2620:1ec:c11::200\ +52127\ +443\ +0\ + + 5c006400650076006900630065005c0068006100720064006400690073006b0076006f006c0075006d00650031005c00700072006f006700720061006d002000660069006c00650073005c00770069006e0064006f007700730061007000700073005c00610066003600390032006200660066002d0036003700370039002d0034003200340066002d0038003700300065002d006600360065003500390063003500300032003300340039005f0031002e0031002e00310030002e0030005f007800360034005f005f00350063003000330037006a0061007200350038003300390072005c0075007700700073006f0063006b006500740063006c00690065006e0074002e006500780065000000\ + \\.d.e.v.i.c.e.\\.h.a.r.d.d.i.s.k.v.o.l.u.m.e.1.\\.p.r.o.g.r.a.m. + .f.i.l.e.s.\\.w.i.n.d.o.w.s.a.p.p.s.\\.a.f.6.9.2.b.f.f.-.6.7.7.9.-.4.2.4.f.-.8.7.0.e.-.f.6.e.5.9.c.5.0.2.3.4.9._.1...1...1.0...0._.x.6.4._._.5.c.0.3.7.j.a.r.5.8.3.9.r.\\.u.w.p.s.o.c.k.e.t.c.l.i.e.n.t...e.x.e...\ + +S-1-5-21-2993214446-1947230185-131795049-1000\ +FWP_AF_INET6\ +S-1-15-2-4163697451-3176919390-1155390458-2883473650-3020241727-522149888-4067122936\ + +0\ + + +FWPM_NET_EVENT_TYPE_CLASSIFY_ALLOW\ + + 125918\ + 50\ + 0\ + 1\ + 1\ + + + +0000000000000000\ + + FWP_CAPABILITIES_FLAG_INTERNET_CLIENT\ FWP_CAPABILITIES_FLAG_INTERNET_CLIENT_SERVER\ + FWP_CAPABILITIES_FLAG_PRIVATE_NETWORK\ + +0\ + + + + 125918\ + FWPP_SUBLAYER_INTERNAL_FIREWALL_WSH\ + FWP_ACTION_PERMIT\ + + + 121167\ + FWPP_SUBLAYER_INTERNAL_FIREWALL_WF\ + FWP_ACTION_PERMIT\ + + + + ``` The following is the filter that permitted the packet to be sent to the target