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


 


WAftring_0-1625249038859.png


 


 For instance, through the group policy outlined below, users can explicitly add intranet proxies to the Home/Work boundry:


 


WAftring_1-1625249038875.png


 


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.


 


WAftring_2-1625249038904.png


 


First would be enabling the subnet definitions as authoritative.


 


WAftring_3-1625249038907.png


 


 


Second, would be grouping the AD subnets into super-nets within Private network ranges for apps.


 


WAftring_4-1625249038913.png


 


 


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


 


WAftring_5-1625249038922.png


 


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.


 


Additional Reading





 

Brought to you by Dr. Ware, Microsoft Office 365 Silver Partner, Charleston SC.

%d bloggers like this: