Windows 10 Always On VPN supports both a user tunnel for corporate network access, and a device tunnel typically used to provide pre-logon network connectivity and to support manage out scenarios. The process of testing Always On VPN is often an iterative one involving trial and error testing to fine tune the configuration parameters to achieve the best experience. As a part of this process it will often be necessary to delete a connection at some point. For the user tunnel the process is simple and straightforward. Simply disconnect the session and delete the connection in the UI.
Deleting a device tunnel connection presents a unique challenge though. Specifically, there is no VPN connection in the UI to disconnect and remove. To delete an Always On VPN device tunnel, open an elevated PowerShell window and enter the following command.
During the initial setup of a NetMotion Mobility gateway server, the administrator must choose to allow either Secure (HTTPS) or Non-secure (HTTP) connections when using the web-based Mobility Console.
Configuring HTTPS
Security best practices dictate HTTPS should be enabled to protect credentials used to log on to the gateway remotely. Immediately after selecting the Secure (https:) option, the administrator is prompted to enter server certificate information. Enter this information and click OK to continue and complete the rest of the configuration as necessary.
Self-Signed Certificate
When logging in to the Mobility console, the administrator is presented with a certificate error indicating there is a problem with the website’s security certificate. This is because the certificate is self-signed by the NetMotion Mobility gateway server and is not trusted.
PKI Issued Certificate
The recommended way to resolve this is to request a certificate from a trusted certification authority (CA). To do this, open the Mobility Management Tool on the Mobility gateway server and click on the Web Server tab.
Click on the Server Certificate button and then click New in the Certificate Request section.
In the SAN (subject alternative name) field of the Optional Extension section enter the Fully Qualified Domain Name (FQDN) of the server using the syntax dns:fqdn. Include both the FQDN and the single-label hostname (short name) separated by a comma to ensure both names work without issue. For example:
dns:nm1.lab.richardhicks.net,dns:nm1
Before requesting a certificate from a CA, the root and any intermediate CA certificates must first be imported. Click the Import button next to each, as required.
Click Copy in the Certificate Request section to copy the Certificate Signing Request (CSR) to the clipboard and then save it to a text file. Now submit the CSR to be signed by the CA using the certreq.exe command. Open an elevated command or PowerShell window and enter the following commands.
Select a CA from the list and click OK, then save the certificate response when prompted.
Click Response and specify the location of the certificate response file saved in the previous step.
Once complete, the newly issued certificate will be in place. Click Close to complete the process.
Click Yes when prompted to restart the Mobility console.
Trusted Certificate
Opening the Mobility Console no longer produces a certificate error message with a certificate installed from a trusted CA.
In addition, if you followed the guidance above and included the single-label hostname in the SAN field, accessing the server using the short name will also work without issue.
Summary
Always select the option to use HTTPS to ensure the highest level of security and protection of credentials when remotely administering a NetMotion Mobility gateway server. For optimal security and to provide the best user experience, use a certificate issued and managed by a trusted CA to prevent certificate errors when opening the Mobility console.
DirectAccess connections are bidirectional, allowing administrators to remotely connect to clients and manage them when they are out of the office. DirectAccess clients use IPv6 exclusively, so any communication initiated from the internal network to remote DirectAccess clients must also use IPv6. If IPv6 is not deployed natively on the internal network, the Intrasite Automatic Tunnel Addressing Protocol (ISATAP) IPv6 transition technology can be used to enable manage out.
ISATAP Supportability
According to Microsoft’s support guidelines for DirectAccess, using ISATAP for manage out is only supported for single server deployments. ISATAP is not supported when deployed in a multisite or load-balanced environment.
“Not supported” is not the same as “doesn’t work” though. For example, ISATAP can easily be deployed in single site DirectAccess deployments where load balancing is provided using Network Load Balancing (NLB).
ISATAP Configuration
To do this, you must first create DNS A resource records for the internal IPv4 address for each DirectAccess server as well as the internal virtual IP address (VIP) assigned to the cluster.
Note: Do NOT use the name ISATAP. This name is included in the DNS query block list on most DNS servers and will not resolve unless it is removed. Removing it is not recommended either, as it will result in ALL IPv6-enabled hosts on the network configuring an ISATAP tunnel adapter.
Once the DNS records have been added, you can configure a single computer for manage out by opening an elevated PowerShell command window and running the following command:
Once complete, an ISATAP tunnel adapter network interface with a unicast IPv6 address will appear in the output of ipconfig.exe, as shown here.
Running the Get-NetRoute -AddressFamily IPv6 PowerShell command will show routes to the client IPv6 prefixes assigned to each DirectAccess server.
Finally, verify network connectivity from the manage out host to the remote DirectAccess client.
Note: There is a known issue with some versions of Windows 10 and Windows Server 2016 that may prevent manage out using ISATAP from working correctly. There’s a simple workaround, however. More details can be found here.
Group Policy Deployment
If you have more than a few systems on which to enable ISATAP manage out, using Active Directory Group Policy Objects (GPOs) to distribute these settings is a much better idea. You can find guidance for creating GPOs for ISATAP manage out here.
DirectAccess Client Firewall Configuration
Simply enabling ISATAP on a server or workstation isn’t all that’s required to perform remote management on DirectAccess clients. The Windows firewall running on the DirectAccess client computer must also be configured to securely allow remote administration traffic from the internal network. Guidance for configuring the Windows firewall on DirectAccess clients for ISATAP manage out can be found here.
ISATAP Manage Out for Multisite and ELB
The configuration guidance in this post will not work if DirectAccess multisite is enabled or external load balancers (ELB) are used. However, ISATAP can still be used. For more information about enabling ISATAP manage out with external load balancers and/or multisite deployments, fill out the form below and I’ll provide you with more details.
Summary
Once ISATAP is enabled for manage out, administrators on the internal network can remotely manage DirectAccess clients wherever they happen to be. Native Windows remote administration tools such as Remote Desktop, Windows Remote Assistance, and the Computer Management MMC can be used to manage remote DirectAccess clients. In addition, enterprise administration tools such as PowerShell remoting and System Center Configuration Manger (SCCM) Remote Control can also be used. Further, third-party remote administration tools such as VNC, TeamViewer, LogMeIn, GoToMyPC, Bomgar, and many others will also work with DirectAccess ISATAP manage out.
Interested in learning more about ISATAP manage out for multisite and external load balancer deployments? Fill out the form below and I’ll get in touch with you.
Windows 10 Always On VPN supports both a user tunnel for corporate network access, and a device tunnel typically used to provide pre-logon network connectivity and to support manage out scenarios. The process of testing Always On VPN is often an iterative one involving trial and error testing to fine tune the configuration parameters to achieve the best experience. As a part of this process it will often be necessary to delete a connection at some point. For the user tunnel the process is simple and straightforward. Simply disconnect the session and delete the connection in the UI.
DirectAccess connections are bidirectional, allowing administrators to remotely connect to clients and manage them when they are out of the office. DirectAccess clients use IPv6 exclusively, so any communication initiated from the internal network to remote DirectAccess clients must also use IPv6. If IPv6 is not deployed natively on the internal network, the Intrasite Automatic Tunnel Addressing Protocol (ISATAP) IPv6 transition technology can be used to enable manage out.
