Diagnosing Network Isolation Issues

This article is contributed. See the original author and article here.

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: deviceharddiskvolume1windowssystem32windowspowershellv1.0powershell.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:Python39python.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.