Windows 10 - Windows Store and Network Isolation (VPN) RRS feed

  • Question

  • We have an issue where the Windows Store doesn't work when our PaloAlto VPN is connected.

    I found that the fix was to add our VPN address range into Network Isolation through Group Policy (Computer Configuration Policies > Administrative Templates Network > Click Network Isolation)

    What is this GPO actually doing. I have read this article but I still can't get my head around it and why it works?

    Monday, July 16, 2018 9:45 AM

All replies

  • Hi,

    If you enable this policy setting, it ensures that apps with the Home/Work Networking capability have appropriate access to your corporate network. These addresses are only accessible to apps if and only if the app has declared the Home/Work Networking capability.

    Windows Network Isolation attempts to automatically discover private network hosts. By default, the addresses configured with this policy setting are merged with the hosts that are declared as private through automatic discovery.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Tuesday, July 17, 2018 6:28 AM
  • Thank you for this. I would expect to have this issue with an App but the whole store fails unless we have this GPO?
    Wednesday, July 18, 2018 11:39 AM
  • Hi,

    Thank you for your post.

    As far as I know, when a VPN tunnel is created with Network Connect, end user may notice the Windows Store is no longer reachable.  Once the tunnel is disconnected, the Windows Store is reachable again. This issue occurs due to the firewall network profile for blocking outbound traffic for Windows Store apps.

    The above steps is allowing only the private network range for network isolation. All other IP ranges that would come through AD sites is not considered as private for network isolation.

    Please note this change is only specific to network isolation. Once the change is applied, a new firewall rule will be created and would override the previous firewall rule. For more information about network isolation with Windows Store apps.


    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact

    Wednesday, July 25, 2018 8:19 AM
  • Hi Chris,

    I've been bitten by this 'bug' in 2019 with our Palo Alto GlobalProtect VPN client.  I'd like to document my findings for you and others who stumble upon this in the future.

    How to break the Store and cause an 0x80131500 or other error:


    1) Configure your system with Palo Alto GlobalProtect VPN client. Connect to VPN. Your VPN adapter will get a blank ( gateway.

    2) In my case, I also had a proxy PAC file which had a 'DIRECT' statement (instead of a PROXY statement), because we capture all default web traffic and send (via GRE) to the proxy, vs explicitly providing a proxy address. (TIP: A separate workaround to this issue, if you can, is to supply a 'PROXY' address outside of your Intranet. I'll explain why that works in a moment.)

    3) Open the Store and receive the error. (If you've successfully loaded the store on a non-VPN connection, it may 'appear' to work until you click on items in the store.  You can [Reset] the Microsoft Store from Settings app, and this will clear the cached content)

    Here's what I believe is happening. Stick with me..

    • The Microsoft Store has a 'Manifest' file that says it can ONLY talk to Internet.
      The file is here: C:\Program Files\WindowsApps\Microsoft.WindowsStore_11909.1002.3.0_x64__8wekyb3d8bbwe\AppxManifest.xml

      And here are the contents:

    • The Microsoft Store app could have also been classified different (as being able to talk to Work/Home networks, too, but the manifest doesn't state it).

      Here's the documentation on the Work/Home vs Internet (client or client+server) network capabilities.
    • This means, as long as the Store (well, technically, Windows Firewall) thinks it is passing the requests from the Store to the 'Internet', it will work.
    • Windows Firewall:  There are 2 (hidden, even if FW is 'Off') rules that are in play:
      InternetClientServer Outbound Default Rule  (allows traffic as long as the machine profile is 'public', not 'domain')
      Block Outbound Default Rule (blocks traffic if rules, including above aren't matched)

      In our case connecting to VPN with the blank gateway (and in my case, also no 'PROXY' definition in the .pac file), Windows assumes it's a Domain (not 'Public') network profile.
    • So, you might ask... "What determines what network a device is connected to?" From the above-linked documentation:
      A network endpoint is considered part of the Home\Work Network if:
         *  It is part of the local subnet of a trusted network.
        *   A device is on a network, and it is authenticated to a domain controller.
        *   Endpoints within the intranet address space are considered private.
            *  The intranet address space is composed of configured Active Directory sites and subnets
        *   Endpoints within the local subnet are considered private.
        *   The device is configured for DirectAccess, and the endpoint is part of the intranet address space.
    • And from the Firewall rules, what happens if it's an "InternetClientServer" (via Manifest) app, and NOT on the 'public' profile? The "Block Outbound Default Rule" blocks the traffic.

      Here are 2 commands to turn on (and turn off) logging to generate trace files. You can use Microsoft Message Analyzer to peek at the ETL files. You'll see the connection blocked to

    Netsh trace start scenario = "netconnection" capture=yes report=yes tracefile=c:\temp\trace.etl
    Netsh wfp capture start
    Netsh trace stop
    Netsh wfp capture stop

    • So, now we've identified 'why' the Store is blocked (because the [or lack of] gateway on the VPN adapter makes Firewall think its next hop is not Public, when the Store only works on an Internet (Public) network.)
    • The group policy comes from an identified issue in Windows 8.x via KB3036542, where the policy was added as a workaround.  What the policy does is to throw out all the 'automatic' calculation of what's Private. Using the Policy, we tell it what is private, and therefore, the rest is Public (Internet), which the Store is permitted to talk on.

      In other words, The "Subnet definitions are authoritative" policy is what tells Windows to ignore the automatic calculation of Private networks, and to only use the list of Private IPs you've defined in the "Private network ranges for apps" policy.

    • My problems with the GPO workaround:
      (1) I must manually maintain a GPO, vs Automatic discovery via Sites and Services
      (2) If I forget to put a local subnet in the list, a Store app that can only talk to 'Private' networks can't talk to it.
      (3) If I install an untrustworthy app configured for 'Internet', this policy effectively exposes any private subnet I haven't defined in the GPO to the untrustworthy app.

    I may be wrong in my analysis/conclusions, but this is how I think this works.

    If anyone finds this helpful, or has further info to share, let me know.

    • Edited by rpertusioH Thursday, October 3, 2019 4:54 PM
    • Proposed as answer by rpertusioH Thursday, October 3, 2019 4:54 PM
    Thursday, October 3, 2019 4:51 PM