none
New AD and largely default GPO blocks access to internet via WiFi

    Question

  • I've been scratching my head over this for days. We're migrating the company network to a new domain (mostly in the Azure cloud) that has a largely default Group Policy. If the domain controller and/or the GPO is not available on the wifi directly, internet access is blocked. This prevents remote employees from using a VPN connection to connect TO the network to provide access to the DC/GPO, the lack of which prevents them from accessing the internet through WiFi. Catch 22.

    If you are connected to an RJ-45 cable vs. WiFi there is no problem, nothing is blocked and you can kickoff the VPN just fine, it seems to be wireless specific.

    I've looked in the Group Policy Management Editor and there is no Wireless Network Policy in place as far as I can tell. All I have is the default placeholder: "New Wireless Network Policy" sample that has nothing set on either the General or Network Preference tabs.

    I've dug through all the settings and I've been unable to find anything that would seem like it would be blocking internet access via wireless connection.

    Do I need to establish a wireless policy in order to prevent internet access being blocked by default? It seems like any policy I establish is for the purpose of locking DOWN Wifi access instead of allowing it, and that's the opposite of what we are trying to accomplish.

    Group Policy isn't really my forte, but nobody else here at the moment has more background than I do and apparently I drew the short straw.

    Any assistance or clarification anyone can provide would be greatly appreciated.

    Thanks in advance for your time and attention.

    Tuesday, November 15, 2016 5:16 PM

Answers

  • Thank you very much for the feedback and follow-up, it's appreciated. I read several articles about limiting wireless access both via group policies and other methods in the process of troubleshooting the problem, the one linked was a good one, thank you.

    As I mentioned, group policy configuration isn't really my area, so I had taken the input of an employee that has been here longer that that was the source of the issue. In taking a step back (in part due to your response, which validated everything I'd found in researching the policy settings) and troubleshooting it as simply a windows client that couldn't access the internet I quickly discovered the true, and blindingly obvious in hindsight, culprit: DNS servers. 

    Long story short, part of the migration to the new setup required static DNS servers being set, but they are unavailable until the VPN is initiated, which cannot be done without a name resolution for the Azure VPN hostname. That was the real catch 22 that was causing the problem.

    Workaround:

    I dashed off a quick hosts file and put together a batch file (I really need to spend some dedicated time learning PowerShell) to install it on client machines and bypass the name resolution of the relevant hosts. It's a temporary workaround while I work on replacing the firewall so I can establish a TLS site-to-site VPN between the Azure cloud and the legacy network.

    The hosts file will still be needed for remote clients though. We really need to be able to initiate a VPN session to establish a connection to Azure before login, but I understand that's beyond scope.

    James


    Monday, November 21, 2016 2:22 PM

All replies

  • Hi,
    As far as I know, there is no built-in group policy to block internet through WIFI, you might need to start from proxy server or firewall or routing that centrally controls the connection to the Internet to see if it helps.
    Here is an article regarding to limit Internet access through Wireless, you could take a look and use for reference:
    How To Limit Internet Access Through Wireless Access
    http://smallbusiness.chron.com/limit-internet-access-through-wireless-access-55375.html
    Please Note: Since the web site is not hosted by Microsoft, the link may change without notice. Microsoft does not guarantee the accuracy of this information.
    Best regards,
    Wendy

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

    Wednesday, November 16, 2016 6:15 AM
    Moderator
  • Hi,

    I am checking how the issue going, if you still have any questions, please feel free to contact us.

    And if the replies as above are helpful, we would appreciate you to mark them as answers, and if you resolve it using your own solution, please share your experience and solution here. It will be greatly helpful to others who have the same question.

    Appreciate for your feedback.

    Best regards,

    Wendy


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

    Monday, November 21, 2016 9:09 AM
    Moderator
  • Thank you very much for the feedback and follow-up, it's appreciated. I read several articles about limiting wireless access both via group policies and other methods in the process of troubleshooting the problem, the one linked was a good one, thank you.

    As I mentioned, group policy configuration isn't really my area, so I had taken the input of an employee that has been here longer that that was the source of the issue. In taking a step back (in part due to your response, which validated everything I'd found in researching the policy settings) and troubleshooting it as simply a windows client that couldn't access the internet I quickly discovered the true, and blindingly obvious in hindsight, culprit: DNS servers. 

    Long story short, part of the migration to the new setup required static DNS servers being set, but they are unavailable until the VPN is initiated, which cannot be done without a name resolution for the Azure VPN hostname. That was the real catch 22 that was causing the problem.

    Workaround:

    I dashed off a quick hosts file and put together a batch file (I really need to spend some dedicated time learning PowerShell) to install it on client machines and bypass the name resolution of the relevant hosts. It's a temporary workaround while I work on replacing the firewall so I can establish a TLS site-to-site VPN between the Azure cloud and the legacy network.

    The hosts file will still be needed for remote clients though. We really need to be able to initiate a VPN session to establish a connection to Azure before login, but I understand that's beyond scope.

    James


    Monday, November 21, 2016 2:22 PM
  • Hi,
    Appreciate for the update and share, it will be greatly helpful to others who have the similar problem.
    Thank you for your effort again.
    Best regards,
    Wendy

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

    Thursday, December 01, 2016 1:27 AM
    Moderator