Hi all, Will Aftring here from Windows Networking Support.
I wanted to chat about how Network Isolation interacts with Universal Windows Platform (UWP) applications and how / why you may want to alter some of these settings in respect to the network and their usage within an Active Directory (AD) integrated domain.
What is this?
As of Windows 8.1+, modern UWP applications have more granularity with determining the scope of operating system (OS) resources they have access to.
These configurations are made in the application manifest and applied to the binary during compilation. There are tools available in the OS to help diagnose issues and make small configuration changes.
How it works
Network Isolation defines network access to the application.
This includes the following:
- Outbound client-initiated requests
- The application reaching out to another resource over the network
- Inbound unsolicited requests
- A client reaching out to the application unsolicited
These network connections are broken down into the following boundaries based on their destination:
- Home/Work: A local home or work network and other machines considered to be local. In a domain environment this is defined by AD Sites and Subnets.
- Internet: Any connection that is not a part of Home/Work is considered internet. This includes proxies that would provide access to the internet.
If any traffic generated by that application that is not defined in the manifest, will be dropped by the Windows Filtering Platform (WFP).
Network Isolation Group Policies
As mentioned above, any endpoint not defined in AD Sites and Subnets is considered to fall within the internet boundary.
However, there are a handful of group policies that allow for the boundaries to be tweaked.
These group polices are found here:
Computer Configuration -> Administrative Templates -> Network -> Network Isolation
For instance, through the group policy outlined below, users can explicitly add intranet proxies to the Home/Work boundry:
More details about each of the available group policies and examples of specific implementations can be found below.
Isolating Apps on Your Network: Define your Network
Benefits of redefining your AD subnets:
WFP defines its filters for sites within AD as concisely as possible. However, due to the nature of how WFP filters define their scope, having many AD subnets can create excessive numbers of WFP filters. As a result of excessive WFP filters, network transmissions may take longer. Additionally, the OS may experience high CPU utilization during the creation of these WFP filters.
A good rule of thumb is with more than 300 AD subnets defined; you may start seeing hits to performance.
A quick way to check the defined AD subnets is with the following PowerShell cmdlet:
PS C:\> Get-ADReplicationSubnet -Filter "*" | Measure-Object | Select-Object Count
If the count of subnets exceeds 300, it is worth investigating redefining your AD subnets or supernetting some AD subnets in the available group policies. Configuring the supernets in group policy is an easy two-step process.
These are the two group policies that control this behavior.
First would be enabling the subnet definitions as authoritative.
Second, would be grouping the AD subnets into super-nets within Private network ranges for apps.
For example, if you have the AD subnets of 192.168.1.0/24 and 192.168.2.0/24, … 192.168.200.0/24 this could easily be included in a super-net of 192.168.0.0/16 reducing the number of filters into a single range that is defined by a single WFP filter.
This reduces the number of WFP filters allowing for a more efficient:
- Creation of WFP filters
- Processing of inbound and outbound network traffic
Windows Firewall Rules per UWP Capability
Another feature of UWP applications is that IT administrators have additional options for how they configure the Windows Firewall around these applications.
UWP specific Windows Firewall settings are made available through the local principals option for a firewall rule. Firewall settings for UWP applications can be applied based on a permission basis (Authorized Users) or on an exclusion basis (Exceptions).
Example: Allowing traffic for specific capabilities on a block rule
These settings can also be configured via group policy as seen in the following document.
Isolating Apps on Your Network: Create Custom Firewall Rules
Loopback traffic
Network communications using the loopback address cannot be used for application-to-application communication for UWP apps because it is restricted by network isolation.
As a consequence of network isolation, Windows disallows establishing a socket connection (Sockets or WinSock) between two UWP apps running on the same machine; whether that's via the local loopback address (127.0.0.0), or by explicitly specifying the local IP address. For details about mechanisms by which UWP apps can communicate with one another, see App-to-app communication.
Source: https://docs.microsoft.com/en-us/windows/uwp/networking/sockets
However, if the application-to-application communication is occurring within the same process then the communication is permitted.
Security Products
Some security applications will adjust components of the OS to leverage the loopback adapter.
Setting any network component, (DNS server, WinHttp proxy / WinInet proxy, etc.…) to the loopback address will lead to the traffic from any UWP applications that leverage those network components to be dropped by WFP. This is by-design behavior; however, it can be worked around if necessary.
Checking for loopback drops
The easiest way to check if there are packet drops due to network isolation is through WFP auditing.
Here is an example of how to check if a UWP applications traffic is being dropped by network isolation due to loopback communication.
First, enable WFP auditing with the following command:
auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
In my scenario, the Windows Store was unable to reach the internet. I reproduced this issue and reviewed the security event log for Event ID 5152:
Log Name: Security
Source: Microsoft-Windows-Security-Auditing
Date: 6/1/2021 7:09:39 AM
Event ID: 5152
Task Category: Filtering Platform Packet Drop
Level: Information
Keywords: Audit Failure
User: N/A
Computer: W2.contoso.com
Description:
The Windows Filtering Platform has blocked a packet.
Application Information:
Process ID: 5884
Application Name: \device\harddiskvolume1\windows\system32\windowspowershell\v1.0\powershell.exe
Network Information:
Direction: Inbound
Source Address: 127.0.0.1
Source Port: 50961
Destination Address: 127.0.0.1
Destination Port: 9000
Protocol: 6
Filter Information:
Filter Run-Time ID: 67901
Layer Name: Receive/Accept
Layer Run-Time ID: 44
From this information we can see that our packet was dropped with filter ID 67901. Let’s proceed to reviewing the filters we have in place to determine the reason for the drop. A dump of the current WFP filters can be generated by running the following command from an Admin Command Prompt:
netsh wfp show state file=wfpstate.xml
Within my wfpstate.xml the filter ID 67901 matches the following item. Based on the name of the filter responsible (AppContainerLoopback) for dropping the packet, I know that the packet is being dropped due to UWP loopback communication.
<item>
<filterKey>{2d336b0c-dcb6-451c-bd3c-e5b22641c539}</filterKey>
<displayData>
<name>AppContainerLoopback</name>
<description>AppContainerLoopback</description>
</displayData>
<flags/>
<providerKey>{decc16ca-3f33-4346-be1e-8fb4ae0f3d62}</providerKey>
<providerData>
<data>ffffffffffffffff</data>
<asString>........</asString>
</providerData>
<layerKey>FWPM_LAYER_ALE_AUTH_RECV_ACCEPT_V4</layerKey>
<subLayerKey>{b3cdd441-af90-41ba-a745-7c6008ff2300}</subLayerKey>
<weight>
<type>FWP_UINT64</type>
<uint64>18446744073709551614</uint64>
</weight>
<filterCondition numItems="2">
<item>
<fieldKey>FWPM_CONDITION_FLAGS</fieldKey>
<matchType>FWP_MATCH_FLAGS_ALL_SET</matchType>
<conditionValue>
<type>FWP_UINT32</type>
<uint32>1</uint32>
</conditionValue>
</item>
<item>
<fieldKey>FWPM_CONDITION_ALE_USER_ID</fieldKey>
<matchType>FWP_MATCH_EQUAL</matchType>
<conditionValue>
<type>FWP_SECURITY_DESCRIPTOR_TYPE</type>
<sd>O:LSD:(A;;CC;;;AC)(A;;CC;;;S-1-15-3-1)(A;;CC;;;S-1-15-3-2)(A;;CC;;;S-1-15-3-3)(A;;CC;;;S-1-15-3-4214768333-1334025770-122408079-3919188833)(A;;CC;;;WD)(A;;CC;;;AN)</sd>
</conditionValue>
</item>
</filterCondition>
<action>
<type>FWP_ACTION_BLOCK</type>
<filterType/>
</action>
<rawContext>0</rawContext>
<reserved/>
<filterId>67901</filterId>
<effectiveWeight>
<type>FWP_UINT64</type>
<uint64>18446744073709551614</uint64>
</effectiveWeight>
</item>
Working around UWP loopback communication
Note, this is intended for debugging purposes only.
In the example below, I will be adding an exemption for the Windows Store.
Let’s start by checking the current configuration of loopback communications using the CheckNetIsolation tool. The syntax, and example output is seen below.
PS C:\> CheckNetIsolation.exe LoopbackExempt -s
List Loopback Exempted AppContainers
OK.
This is the output we would expect to see with no loopback exempt applications.
With that in mind, lets add my exemption for the Windows Store. First thing we need to do is find the AppID of the Windows Store. To do this we can run the PowerShell cmdlet Get-StartApps with one of the following syntaxes.
PS C:\> Get-StartApps # For all applications
Name AppID
---- -----
Blend 2019 Blend.28500c9f
Python 3.9 (64-bit) C:\Python39\python.exe
Microsoft Store Microsoft.WindowsStore_8wekyb3d8bbwe!App
PS C:\> Get-StartApps -Name "Microsoft Store" # Or for a specific application
Name AppID
---- -----
Microsoft Store Microsoft.WindowsStore_8wekyb3d8bbwe!App
The resulting AppID can be trimmed:
- from Microsoft.WindowsStore_8wekyb3d8bbwe!App
- to Microsoft.WindowsStore_8wekyb3d8bbwe
Now adding the exemption for the rule will can be done using CheckNetIsolation with the syntax below.
PS C:\> CheckNetIsolation.exe LoopbackExempt -a -n="Microsoft.WindowsStore_8wekyb3d8bbwe"
OK.
Confirm the loopback exemption rule has been added to the exemption list, with the syntax below.
PS C:\> CheckNetIsolation.exe LoopbackExempt -s
List Loopback Exempted AppContainers
[1] -----------------------------------------------------------------
Name: microsoft.windowsstore_8wekyb3d8bbwe
SID: S-1-15-2-1609473798-1231923017-684268153-4268514328-882773646-2760585773-1760938157
OK.
And now there is an exemption added for the Windows Store!
If you wanted to add all current UWP applications to the loopback exemption list, you could use a PowerShell script like this. Note, this may vary depending on AppID format and use at your own risk.
(Get-StartApps).AppID | ForEach-Object {
$UWPApp = $_.Split("!")[0]
CheckNetIsolation.exe LoopbackExempt -a -n="$UWPApp"
}
UWP listening on the loopback for traffic
Currently, it is not supported for UWP application to listen on the loopback adapter outside of Visual Studio.
This behavior is outlined in our documentation.
Note Loopback is permitted only for development purposes. Usage by a Windows Runtime app installed outside of Visual Studio is not permitted. Further, a Windows Runtime app can use an IP loopback only as the target address for a client network request. So, a Windows Runtime app that uses a DatagramSocket or StreamSocketListener to listen on an IP loopback address is prevented from receiving any incoming packets.
Source: Windows 8 Development: How to enable loopback for network access
Determining what traffic an application is using
If the traffic an application is using is unknown, CheckNetIsolation can be used to determine how the OS is detecting the network traffic of a UWP application.
In our example, I will be investigating the Windows Store which will only be accessing resources out on the open internet and will not be receiving any unsolicited connections.
As seen in the loopback example we can pull the AppID with Get-StartApps using the syntax below.
PS C:\> Get-StartApps -Name "Microsoft Store"
Name AppID
---- -----
Microsoft Store Microsoft.WindowsStore_8wekyb3d8bbwe!App
As a reminder be sure to trim the trailing !App from the AppID.
Now using the CheckNetIsolation syntax below I can start a debug session to determine how the OS is detect the network boundary of traffic for the Windows Store.
PS C:\> CheckNetIsolation.exe Debug -n="Microsoft.WindowsStore_8wekyb3d8bbwe"
Network Isolation Debug Session started.
Reproduce your scenario, then press Ctrl-C when done.
Once I’ve reproduced my issue, I can input Ctrl+C to stop the data collection and a report similar to the one below will be generated.
PS C:\> CheckNetIsolation.exe Debug -n="Microsoft.WindowsStore_8wekyb3d8bbwe"
Network Isolation Debug Session started.
Reproduce your scenario, then press Ctrl-C when done.
Collecting Logs.....
Summary Report
Network Capabilities Status
----------------------------------------------------------------------
InternetClient Used and Declared
InternetClientServer Not Used and Insecure
Detailed Traffic Report
----------------------------------------------------------------------
InternetClient Used and Declared
------------------------------------------------------------------
23.196.35.33 23.196.35.33 23.196.35.33 104.87.85.147
104.87.85.147 23.218.218.171 104.87.85.147 104.87.85.147
104.87.85.147 104.87.85.147 104.87.85.147 104.87.85.147
23.220.124.10
InternetClientServer Not Used and Insecure
------------------------------------------------------------------
OK.
In my scenario, only InternetClient traffic (meaning outbound traffic to endpoints outside my work boundary) was detected by the debug scenario.
Closing Notes:
I know I covered lots of in-depth information here, I appreciate if you have made it this far. Network isolation can be tricky, but with the information above you should be able to get started diagnosing issues in your environment. For additional information please see the section below.
Additional Reading
- How to set network capabilities (HTML)
- Debug network isolation issues
- Case 1: UWP app connects to Internet target address with all capabilities
- Isolating Microsoft Store Apps on Your Network