Network Isolation of Windows Modern Apps – How Apps work with Akamai Internet Caching Servers in Windows 8/8.1
Good morning AskPerf! Mario Liu here from the Windows 8/8.1 Support Team. Today I’d like to discuss a Windows Modern App connectivity issue I’ve worked over the past few months.
We have several Enterprise customers who have deployed Windows 8 and 8.1 in their environments. However, after joining the machine to the domain, we discovered that numerous Windows Modern Apps could not display the contents correctly. For example, if we launched the Weather App, we saw the message “This page failed to load”:
On the surface, this looks like a network connectivity issue, however other network related programs ran fine. A Network Trace was captured, but we could not find any dropped packets.
After further troubleshooting, we found that the same Windows 8/8.1 machines worked if they were outside of their corporate network. This gave us a clue that something inside their environment is causing the issue. In one step, we noticed that if the Firewall was disabled, the Modern App ran fine. Obviously turning the firewall off is not recommended.
After lots of additional troubleshooting steps were done, we discovered that the Akamai Internet Caching Servers had a hand in this issue. The Windows Firewall Service blocked the traffic to Akamai devices, but why would it do this? Why would a Modern App have network connectivity issues to Akamai devices?
To answer this question, first we need understand what Akamai Internet Caching Server is. It is a widely used content management solution worldwide. The main purpose of it is to save the web contents (mostly static) as the cache on the server. So next time a client machine tries to reach the same website, it actually reaches the cache on the local Akamai Server instead of taking longer time to reach the real contents on the remote web server. By doing this, we save a lot network traffic and speed up the contents delivery. So, the Akamai Internet Caching Server plays a similar role as an Internet Proxy Server, but from a web content management perspective. It basically delivers the contents to Windows clients on behalf of real/live web server.
OK, so now that we understand Akamai’s role, let’s switch back to the Windows Modern App. In Windows, there is an important feature called Windows Store App Network Isolation. Modern Apps are network isolated depending on the network capabilities the app developer chooses. An enterprise private network is protected and only available to those apps that declare the privateNetworkClientServer capability in the app manifest. There are very few Modern Apps in the Microsoft store that work on a private network. Even though users can very easily download and install any kind of app, the app cannot talk to the enterprise network because the app can only talk to the public network. In most cases, what is a private / public internet network is automatically detected, which means the Modern App knows to reach public internet even when a Windows 8/8.1 machine is running in a corporate (private) environment. But what happens if we bring the Akamai Internet Caching Server into this scene? Instead of letting Modern App reach the real contents on the remote web server via public internet, the Modern App is forced to talk to the Akamai device which is on the corporate (private) network. Remember, very few Modern Apps are approved to work on a private network ONLY. If the apps try to reach private network, the firewall will block it. Here is a way you can check to see if your machine is hitting this problem:
1. Enable WFP (Windows Filtering Platform) auditing by running the following command via elevated command prompt:
auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable
2. Reproduce the issue.
3. Go to event viewer -> Windows Logs -> Security. You should see some event ID 5152 which means Filtering Platform Packet Drop.
4. Look at one of these events and you should find this similar information. Note: 192.168.0.10 is Akamai server’s address in this example.
The Windows Filtering Platform has blocked a packet.
Application Information:
Process ID: 2712
Application Name: \device\harddiskvolume2\windows\system32\wwahost.exe
Network Information:
Direction: Outbound
Source Address: 192.168.0.30
Source Port: 50571
Destination Address: 192.168.0.10
Destination Port: 80
Protocol: 6
Filter Information:
Filter Run-Time ID: 71620
Layer Name: Connect
Layer Run-Time ID: 48
Wwahost.exe is the Modern App process. As you can see, WFP blocked this traffic with Filter ID 71620 because it tried to reach a private IP address. This filter is called Block Outbound Default Rule. If you want to know how I can tell this filter’s name, you can do netsh.exe wfp capture start via elevated command prompt when you reproduce the issue. This will generate a wfpdiag.cab file and in this cab you can see wfpdiag.xml. Now open this xml file to correlate the filter name and ID.
So, at this point, we now know that Akamai is filtering the cached Internet traffic. That internet cache however is hosted in the private network. Akamai internet cache is essentially the internet network and needs to be deployed as such.
There are several solutions. But they can be essentially classified in two types:
Type 1: Either the Akamai servers must be deployed outside of the private network, or
Type 2: The Akamai servers must be declared explicitly as proxies who live in the private network
Microsoft’s recommendation is Type 1 as the enterprise cannot control much of what the Akamai devices do. So, putting the device just outside of the corporate firewall on a different address space or outside of enterprise subnet would appear to be a better solution. However, if this requires a fundamental change of your infrastructure, the Type 2 solution can also be guaranteed to work.
Below we cover some solutions of how the Akamai Servers can be deployed.
Solution 1 – Akamai servers on their own IP space.
Akamai servers are deployed outside of the DMZ and they are given an address space different from the one provided to the company. In this scenario the ISP might participate or even the company can simply not provision the subnet given to Akamai anywhere else.
Solution 2 – Akamai servers are outside of AD sites and Subnets.
Akamai servers are given an IP address space that is not one included in the AD sites and Subnets configuration of active directory. In theory it should be a security issue that an external device not belonging to the corporation is included in the AD sites and subnets as it providing it with access that the enterprise does not want to provide. Hence this approach is not only an appropriate deployment of network isolation but an appropriate deployment of AD in general and a good tightening of the network.
Solution 3 – Akamai servers are removed manually from the private network by using the Network isolation Group Policy controls to override the private network.
Network Isolation Group Policy controls allows Group Policy admins to add private network subnets. It also allows them to completely override the private network definitions in AD sites and subnets and hence carve out any IP space that shouldn’t be considered part of the private network of the enterprise.
Let’s assume your corporate IP address space ranges from 192.168.0.1 to 192.168.0.255 and you have two Akamai servers with IP 192.168.0.10 and 192.168.0.11.
Here is the example to implement this solution:
- Open the Group Policy Management snap-in (gpmc.msc) and edit the Default Domain Policy.
- From the Group Policy Management Editor, expand Computer Configuration, expand Policies, expand Administrative Templates, expand Network, and click Network Isolation.
- In the right pane, double-click Private network ranges for apps.
- In the Private network ranges for apps dialog box, click Enabled. In the Private subnets text box, type the private subnets for your intranet, and remove Akamai servers.
In this example the values are 192.168.0.1-192.168.0.9; 192.168.0.12-192.168.0.255 in the Private subnets text box. Note we have excluded 192.168.0.10 and 192.168.0.11 since they are Akamai’s.
5.Double-click Subnet definitions are authoritative, click Enabled.
Solution 4 – Akamai servers are configured as proxies by using the Network Isolation Group Policy controls to declare them as proxies.
The Network Isolation GP controls also allow admins to add internet proxies. It can also be used to completely override the proxy discovery mechanisms provided by default with a preferred proxy definition.
The enterprise admin can easily use the network isolation GP internet proxy controls to add the Akamai servers as internet content proxies.
Here is the example to implement this solution:
- Open the Group Policy Management snap-in (gpmc.msc) and edit the Default Domain Policy.
- From the Group Policy Management Editor, expand Computer Configuration, expand Policies, expand Administrative Templates, expand Network, and click Network Isolation.
- Double-click Internet proxy servers for apps. Click Enabled, and then in the Domain Proxies text box, type the IP addresses of your Internet proxy servers, separated by semicolons. In this example the values are 192.168.0.10; 192.168.0.11
- Double-click Proxy definitions are authoritative. Ensure that the Not Configured default value is selected to add these proxies to other discovered http proxies.
For more information about the feature of Network Isolation of Windows Modern Apps, please refer to:
Isolating Windows Store Apps on Your Network
How to set network capabilities
-Mario