All posts tagged network

Always On VPN Device Tunnel Missing in Windows 10 UI

Always On VPN Device Tunnel Missing in Windows 10 UIUnlike DirectAccess, Always On VPN connections are provisioned to the user, not the machine. Beginning with Windows 10 release 1709 Microsoft introduced the device tunnel option to provide feature parity with DirectAccess. The device tunnel provides pre-logon network connectivity to support important deployment scenarios such as logging on without cached credentials and unattended remote systems management.

Device Tunnel Configuration

Guidance for creating and deploying a device tunnel connection can be found here. It’s important to note that the device tunnel is always on by default. Also, there can only be a single device tunnel configured per device. You must remove an existing device tunnel before configuring a new one.

Known Issues

After configuring a Windows 10 Always On VPN device tunnel the administrator may notice two anomalies. First, the device tunnel is missing in the Windows UI after it is created. Second, viewing the status of the device tunnel connection using PowerShell indicates the connection is “disconnected” even though it is connected.

Device Tunnel Missing

As you can see below, event though both a device and user tunnel have been provisioned, the Windows UI reports only a single Always On VPN connection, that being the user connection.

Always On VPN Device Tunnel Missing in Windows 10 UI

However, the device tunnel does appear in the Network Connections control panel applet (ncpa.cpl), as shown here.

Always On VPN Device Tunnel Missing in Windows 10 UI

This is expected and by design. The device tunnel is not displayed to the user in the Windows UI as it is provisioned to the machine, not the user. It appears on the Control Panel because the applet is capable of enumerating both user and system connections.

Device Tunnel Disconnected

The status of the Windows 10 Always On VPN device tunnel connection can be viewed by running the Get-VpnConnection -AllUserConnection PowerShell command. However, at the time of this writing, PowerShell always reports the connection status as “Disconnected”. This appears to be a bug; one which Microsoft is hopefully working to address.

Always On VPN Device Tunnel Missing in Windows 10 UI

Summary

The Windows 10 Always On VPN device tunnel option allows administrators to enable scenarios previously supported with DirectAccess, including logging on without cached credentials and unattended remote support. Not all deployments require a device tunnel, but it is an important option available to administrators to address specific use cases.

Additional Information

Windows 10 Always On VPN Device Tunnel Configuration using PowerShell

Windows 10 Always On VPN RasMan Device Tunnel Failure

Deleting a Windows 10 Always On VPN Device Tunnel

 

34 Comments
by Richard M. Hicks on October 31, 2018  •  Permalink
Posted in Always On VPN, AOVPN, DirectAccess, Enterprise, enterprise mobility, PowerShell, Remote Access, RRAS, Security, VPN, Windows 10
Tagged , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on October 31, 2018

https://directaccess.richardhicks.com/2018/10/31/always-on-vpn-device-tunnel-missing-in-windows-10-ui/

Always On VPN Routing Configuration

Windows 10 Always On VPN Routing ConfigurationWhen configuring Windows 10 Always On VPN, the administrator must choose between force tunneling and split tunneling. When force tunneling is used, all network traffic from the VPN client is routed over the VPN tunnel. When split tunneling is used, the VPN client must be configured with the necessary IP routes to establish remote network connectivity to on-premises resources. How those routes are established is a common source of confusion. This article provides guidance for properly configuring routing for Always On VPN clients.

Class Based Routing

IP addresses are assigned to Windows 10 Always On VPN clients from either a static pool of addresses configured by the administrator or by DHCP. If split tunneling is enabled, the client will also be assigned a class-based route that is derived from the IP address assigned to it by the VPN server, by default. If the client is assigned an IP address from the Class A network, a corresponding /8 prefix is used. For Class B networks a /16 prefix is defined, and for Class C networks a /24 prefix is used.

As an example, if the VPN server assigns the client an IP address of 10.21.12.103, a route to the 10.0.0.0/8 network is added to the client’s routing table, as shown here.

Windows 10 Always On VPN Routing Configuration

Complex Networks

This default class-based route is of limited use though, and is only applicable when the internal network is simple and VPN clients are assigned IP addresses from the same subnet class. In the example above, if the entire internal network resides in the 10.0.0.0/8 Class A address space, all resources will be reachable by the VPN client. Any resources in the Class B or Class C subnet ranges would be unreachable without additional configuration.

Route Configuration

To configure routing for Windows 10 Always On VPN clients, first disable the default class-based route by defining the following element in ProfileXML as shown here.

<VPNProfile>
   <NativeProfile>
      <DisableClassBasedDefaultRoute>true</DisableClassBasedDefaultRoute>
   </NativeProfile>
</VPNProfile>

Next, enable specific routes as needed by defining the following element(s) in ProfileXML. The example below defines routes for all private RFC 1918 networks.

<VPNProfile>
   <Route>
      <Address>10.0.0.0</Address>
      <PrefixSize>8</PrefixSize>
   </Route>
   <Route>
      <Address>172.16.0.0</Address>
      <PrefixSize>12</PrefixSize>
   </Route>
   <Route>
      <Address>192.168.0.0</Address>
      <PrefixSize>16</PrefixSize>
   </Route>
</VPNProfile>

Once implemented, the VPN client’s routing table will appear as shown here.

Windows 10 Always On VPN Routing Configuration

Summary

Proper routing is crucial for ensuring full network connectivity and access to internal resources for Windows 10 Always On VPN clients. When split tunneling is employed, avoid using the default class-based route and instead define specific routes using ProfileXML as required.

Additional Information

Always On VPN Client DNS Server Configuration

Deploying Windows 10 Always On VPN with Microsoft Intune

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Certificate Requirements for SSTP

284 Comments
by Richard M. Hicks on July 23, 2018  •  Permalink
Posted in Always On VPN, AOVPN, enterprise mobility, Mobility, Remote Access, VPN, Windows 10, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on July 23, 2018

https://directaccess.richardhicks.com/2018/07/23/always-on-vpn-routing-configuration/

Top 5 DirectAccess Troubleshooting Tips

Top 5 DirectAccess Troubleshooting TipsDirectAccess is a thing of beauty when everything is working as it should. When it isn’t, troubleshooting can be quite challenging. DirectAccess relies on many Windows platform technologies such as Active Directory for authentication, PKI for certificate management, group policy for settings deployment, IPsec for encryption, and IPv6 for transport. With so many dependencies, locating the source of the problem can be a difficult and daunting task.

I’m frequently called upon to help organizations of all sizes with DirectAccess troubleshooting. While this post is not intended to be a detailed, prescriptive guide for DirectAccess troubleshooting, I did want to share some common troubleshooting tips based on many years of troubleshooting DirectAccess.

Here are my top 5 DirectAccess troubleshooting tips:

  1. Check Prerequisites – Before diving in and collecting network traces and scouring event logs for clues as to why DirectAccess isn’t working, it’s essential to start at the beginning. Often the source of trouble is missing or misconfigured prerequisites. For example, is the DirectAccess client running a supported operating system? Remember, clients must be running Windows 10 Enterprise or Education, Windows 8.x Enterprise, or Windows 7 Enterprise or Ultimate. Also, ensure that the Windows firewall is enabled on DirectAccess servers and clients, that certificates are installed and valid (trusted, correct EKU, etc.), and that the DirectAccess settings GPO has been applied to servers and clients.
  2. Validate External Connectivity – If you are following implementation and security best practices for DirectAccess, the DirectAccess server will be in a perimeter/DMZ network behind an edge firewall. The firewall must be configured to allow inbound TCP port 443 only. If the firewall is also performing Network Address Translation (NAT), the NAT rule must be configured to forward traffic to the DirectAccess server’s dedicated or virtual IP address (VIP), or the VIP of the load balancer. Watch for routing issues when using load balancers too. It’s a good idea to confirm external connectivity using the Test-NetConnection PowerShell command. Even better, use the open source tool Nmap for more thorough testing.
  3. Remove Third Party Software – I can’t tell you how many times I’ve resolved DirectAccess connectivity issues by removing (not just disabling!) third party software on the client and/or server. It’s not uncommon for third-party security software to interfere with IPsec and/or IPv6 communication, both of which are vital to DirectAccess. If your DirectAccess troubleshooting efforts reveal no underlying issues with prerequisites or external connectivity, I’d suggest removing (at least temporarily) any third-party software and testing again.
  4. Isolate Environmental Issues – Occasionally other settings applied manually or via Active Directory group policy will interfere with DirectAccess. Examples include IPv6 being disabled in the registry, IPv6 transition technologies required to support DirectAccess are turned off, essential firewall rules for DirectAccess are disabled, or manipulating local security settings such as Access this computer from the network. To assist with troubleshooting it might be necessary to temporarily place DirectAccess clients and servers in their own dedicated Organizational Units (OUs) and block inheritance to isolate the configuration as much as possible. In addition, if DirectAccess clients are servers are provisioned using images or templates, testing with a clean build straight from the installation source (ISO or DVD) can be helpful.
  5. Check for Unsupported Configurations – If DirectAccess isn’t working, it might be possible the configuration you are trying to use is not supported. Examples including strong user authentication with OTP when force tunneling is enabled, provisioning Windows 7 clients when using Kerberos Proxy authentication, or provisioning Windows 10 clients when Network Access Protection (NAP) integration is enabled. These configurations won’t work and are formally documented here.

This is by no means a comprehensive or exhaustive troubleshooting guide. For more information and additional DirectAccess troubleshooting guidance I would encourage you to purchase my book Implementing DirectAccess with Windows Server 2016, which has an entire chapter devoted just to troubleshooting. In addition, watch my DirectAccess video training courses on Pluralsight for details and information about DirectAccess installation, configuration, management, support, and troubleshooting. And if you’re still struggling to resolve a DirectAccess problem, use the form at the bottom of this page to contact me to inquire about additional troubleshooting help.

Additional Resources

Microsoft Windows DirectAccess Client Troubleshooting Tool
DirectAccess and Windows 10 Professional
DirectAccess Troubleshooting with Nmap
DirectAccess Unsupported Configurations
Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course on Pluralsight
Implementing DirectAccess with Windows Server 2016 Book

Need assistance with DirectAccess troubleshooting? Complete the form below and I’ll get in touch with you.

1 Comment
by Richard M. Hicks on May 15, 2017  •  Permalink
Posted in DirectAccess, IPv6, IPv6 Transition, PowerShell, Remote Access, Security, SSL and TLS, troubleshooting, Windows 10, Windows 7, Windows 8, Windows 8.1, Windows Server 2012, Windows Server 2012 R2, Windows Server 2016
Tagged , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Posted by Richard M. Hicks on May 15, 2017

https://directaccess.richardhicks.com/2017/05/15/top-5-directaccess-troubleshooting-tips/

« Older Posts
Newer Posts »