Always On VPN and RRAS in Azure

Always On VPN and RRAS in AzureWhen deploying Windows 10 Always On VPN, it may be desirable to host the VPN server in Microsoft’s Azure public cloud. Recently I wrote about Always On VPN deployment options in Azure, and in that post I indicated that deploying Windows Server and the Routing and Remote Access Service (RRAS) was one of those options. Although not formally supported by Microsoft, RRAS is often deployed in Azure because it is cost-effective, easy to manage, and provides flexible scalability.

Supportability

It’s important to state once again that although it is possible to successfully deploy Windows Server with RRAS in Azure to support Always On VPN, as of this writing it is not a formally supported workload. If the administrator makes the decision to deploy RRAS in Azure, they must also accept that Microsoft may refuse to assist with troubleshooting in this specific deployment scenario.

Always On VPN and RRAS in Azure

Reference: https://support.microsoft.com/en-us/help/2721672/microsoft-server-software-support-for-microsoft-azure-virtual-machines

Azure Prerequisites

The configuration of RRAS is identical to on-premises, with a few additional steps required by Azure infrastructure.

Windows Server

RRAS can be configured on any Windows Server virtual machine supported in Microsoft Azure. As with on-premises deployments, Server GUI and Core are supported. Domain-join is optional. The server can be deployed with one network interface or two.

Public IP

A public IP address must be assigned to the VPN server’s external network interface, or the internal interface if the VPN server is configured with a single network adapter. The IP address can be static or dynamic. When using a dynamic IP address, configure a CNAME record in DNS that points to the name configured for the IP address in Azure. If using a static IP address, an A host record can be configured pointing directly to the IP address.

Network Security Group

A Network Security Group (NSG) must be configured and assigned to the VPN server’s external or public-facing network interface that allows the following protocols and ports inbound.

  • TCP port 443 (SSTP)
  • UDP port 500 (IKEv2)
  • UDP port 4500 (IKEv2 NAT traversal)

RRAS in Azure

Below are the infrastructure requirements for supporting Windows Server RRAS VPN in Azure.

Client IP Subnet

Static IP address pool assignment must be used with RRAS. Using DHCP for VPN client IP address assignment in Azure is not supported and will not work. The IP subnet assigned to VPN clients by RRAS must be unique and not overlap with any existing Azure VNet subnets. If more than one VPN server is deployed, each server should be configured to assign a unique subnet for its clients.

IP Forwarding

IP forwarding must be enabled on the VPN server’s internal network interface. Follow the steps below to enable IP forwarding.

1. In the Azure portal, open the properties page for the internal network interface for the VPN server.
2. Click IP configurations in the navigation pane.
3. Click Enabled next to IP forwarding.
4. Click Save.

Always On VPN and RRAS in Azure

Routing

Azure must be configured to route IP traffic from VPN clients back to the VPN server. Follow the steps below to create and assign a routing table in Azure.

1. Click Create Resource.
2. Enter “Route Table” in the search field and press Enter.
3. Click Route Table.
4. Click Create.
5. Enter a descriptive name for the route table in the Name field.
6. Choose an appropriate subscription from the Subscription drop-down list.
7. Select the resource group where the VPN server(s) reside.
8. Select the best location to deploy the route table resource from the Location drop-down list.
9. If the administrator wants to have the VPN client IP subnet route information published automatically, select Enabled for Virtual network gateway route propagation.
10. Click Create.

Always On VPN and RRAS in Azure

Once complete, follow the steps below to define the route for VPN clients.

1. Open the properties page for the route table.
2. Click Routes in the navigation pane.
3. Click Add.
4. Enter a descriptive name in the Route name filed.
5. Enter the IP subnet assigned to VPN clients in the Address prefix field.
6. Select Virtual appliance from the Next hop type drop-down list.
7. Enter the IPv4 address assigned to the VPN server’s internal network interface in the Next hop address field.
8. Click Ok.
9. Repeat the steps above for each VPN server configured in Azure.

Always On VPN and RRAS in Azure

Finally, follow the steps below to assign the route table to an Azure VNet subnet.

1. Open the properties page for the route table.
2. Click Subnets in the navigation pane.
3. Click Associate.
4. Click Virtual network.
5. Choose the appropriate Azure VNet.
6. Click Subnet.
7. Choose an Azure VNet subnet to assign the route table to.
8. Click Ok.
9. Repeat the steps above to assign the route table to any Azure VNet subnet that must be accessible by VPN clients. If VPN clients need access to on-premises resources via Azure site-to-site gateway, assign the route table to the Azure VPN gateway subnet.

Always On VPN and RRAS in Azure

Note: Azure only supports the assignment of one route table per subnet. If a route table is currently assigned, the VPN client subnet route can be added to an existing route table, if necessary.

Summary

Administrators have many choices when it comes to support Always On VPN connections hosted in Azure. RRAS on Windows Server can be an effective solution, assuming you can live without formal support. If having a formally supported solution is a hard requirement, consider deploying Always On VPN using the native Azure VPN gateway or another third-part Network Virtual Appliance (NVA).

Additional Information

Azure deployment options

Always On VPN and RRAS with Single NIC

Always On VPN and RRAS with Single NICI’m commonly asked “can Windows Server with Routing and Remote Access Service (RRAS) be configured with a single network interface?” This is likely because the official Microsoft documentation references only a multihomed dual NIC configuration, leading many to believe it is a strict requirement.

Single NIC

Deploying Windows Server RRAS with a single network interface is indeed supported and works without issue. There are no functional limitations imposed by using a single network interface. All features are fully supported in this scenario. The choice to use one or two network interfaces is purely a design choice, driven by several factors such as current network configuration and security requirements.

Dual NIC

Although a single NIC configuration is fully supported, there are some important advantages associated with mulithome dual NIC deployments. The following should be considered when deciding between single NIC and dual NIC VPN configurations.

Traffic Segmentation

Having separate internal and external network connections provides logical and physical separation of trusted and untrusted network traffic. Terminating connections from Always On VPN clients on the Internet in an isolated perimeter or DMZ network yields positive security benefits.

Firewall Configuration

Using two network interfaces allows for a more restrictive Windows Firewall policy to be applied to the external interface. This reduces the exposure of running services on the RRAS server to untrusted networks. This is especially critical if the VPN server is Windows Server RRAS and it is joined to a domain.

Network Performance

For very busy RRAS servers, having two network interfaces can improve network performance. With two network interfaces, network traffic is distributed between two network adapters, reducing utilization on each interface.

Dual NIC Best Practices

When deploying an RRAS server with dual NICs, the following recommendations for network interface configuration should be followed.

IP Addressing

Each network interface must be assigned an IP address from a unique subnet. Having both NICs on the same subnet is not supported.

Default Gateway

The default gateway should be configured on the external facing network interface only. The internal interface should not be configured with a gateway. Rather, static routes to any remote internal networks should be configured.

To add a static route on a Windows Server, open an elevated PowerShell command window and run the following command.

New-NetRoute -AddressFamily IPv4 -DestinationPrefix 10.0.0.0/8 -InterfaceAlias ‘Internal’ -NextHop 172.21.12.254

DNS

For domain-joined RRAS servers, corporate DNS servers should be configured on the Internal network interface only. No DNS servers should be configured on the external interface. If the server is not joined to a domain, DNS servers can be configured on whichever interface has connectivity to the defined DNS servers.

NAT

When the RRAS server is behind a device performing Network Address Translation (NAT), the NAT should be configured to translate only the destination address (DNAT). This allows the VPN server (or load balancer for multiserver deployments) to see the client’s original source IP address, which ensures efficient traffic distribution and meaningful log data.

Client, Service, and Protocol Bindings

All unnecessary clients, services, and protocols should be unbound from the external network interface. It is recommended that only the IPv4 and IPv6 protocols be enabled on the external interface, as shown here. Again, this reduces exposure for the server to the untrusted external network.

Always On VPN and RRAS with Single NIC

Summary

The dual NIC, multihomed configuration is generally recommended for most deployments as it offers security and performance advantages over the single NIC configuration. For organizations with less demanding security requirements, a single NIC deployment can be deployed safely without compromising functionality or supportability. In addition, a single NIC deployment may be the best option when multiple networks aren’t readily available.

Additional Information

Windows 10 Always On VPN and Windows Server Routing and Remote Access (RRAS)

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

Windows 10 Always On VPN Options for Azure Deployments

Windows 10 Always On VPN Hands On Training

Error Importing Windows Server RRAS Configuration

Error Importing Windows Server RRAS Configuration Windows Server and the Routing and Remote Access Service (RRAS) is a popular choice for Windows 10 Always On VPN deployments. It is easy to implement and support, offers flexible scalability, and is cost-effective. In addition, it provides support for a TLS-based VPN protocol which is required for many deployments.

Configuration Backup

When deploying RRAS to support Always On VPN, it’s an excellent idea to export the configuration once all settings have been finalized. Often this is done by opening an elevated command window and running netsh.exe ras dump and piping the output to a text file, as shown here.

netsh.exe ras dump > rasconfig.txt

Import Error

Importing a saved configuration is accomplished by opening an elevated command window and running netsh.exe exec [filename], as shown here.

netsh.exe exec rasconfig.txt

Oddly, this doesn’t work by default. The import will fail and return the following error message.

“The following command was not found: ■.”

Error Importing Windows Server RRAS Configuration

Root Cause

Importing the RRAS configuration fails because the default configuration output is saved in Unicode format. Inexplicably this encoding is not recognized by netsh.exe when importing the configuration.

Workaround

Follow the steps below to save the configuration file in a format that can be imported using netsh.exe.

1. Open the exported configuration file using notepad.exe.
2. From the Menu bar choose File > Save As.
3. From the Encoding drop-down list choose ANSI.
4. Click Save.

Error Importing Windows Server RRAS Configuration

Once complete, import the file using netsh.exe exec [filename]. Restart the RemoteAccess service to apply the changes.

PowerShell

Administrators can use PowerShell to export the RRAS configuration and ensure the correct encoding format is used by default. To do this, open an elevated PowerShell window and run the following command.

Invoke-Command -ScriptBlock {netsh ras dump} | Out-File [filename] -Encoding ASCII

Additional Information

Windows 10 Always On VPN and Windows Server Routing and Remote Access Service (RRAS)

Windows 10 Always On VPN Protocol Recommendations for Windows Server Routing and Remote Access Service (RRAS)

Always On VPN Device Tunnel and Certificate Revocation

Always On VPN Device Tunnel and Certificate RevocationRecently I wrote about denying access to Windows 10 Always On VPN users or computers. In that post I provided specific guidance for denying access to computers configured with the device tunnel. To summarize, the process involved exporting the device certificate from the issuing Certification Authority (CA) server and placing it in the Untrusted Certificates certificate store on each VPN server. In theory, simply revoking the device certificate should be all that’s required to prevent device tunnel connections.

Revocation Check Failure

As it turns out, a bug in Windows Server Routing and Remote Access prevents this from working as expected. Windows Server 2012 R2, 2016, and 2019 all fail to check the Certificate Revocation List (CRL) for IKEv2 VPN connections using machine certificate authentication (for example an Always On VPN device tunnel).

Update for Windows Server

Microsoft recently made a fix for this issue available for Windows Server 2016. It is included in the June 18, 2019 update KB4503294 (build 14393.3053). A fix for Windows Server 2019 is forthcoming. Windows Server 2012 R2 will not be updated. It is recommended that you upgrade to a later version of the Windows Server operating system to  address this issue.

Note: This fix is now available for Windows Server 1903 (semi-annual channel). It is included in the June 27, 2019 update KB4501375 (build 18362.207).

Enable Revocation Check

Additional configuration is required to enable support for CRL checking. Microsoft published guidance for configuring CRL revocation checks for IKEv2 VPN connections using machine certificate authentication here. Specifically, administrators must enable the RootCertificateNameToAccept parameter and set a registry key to enable this functionality.

Open an elevated PowerShell window and run the following commands to enable CRL checking for IKEv2 VPN connections using machine certificate authentication.

$Thumbprint = ‘Root CA Certificate Thumbprint’
$RootCACert = (Get-ChildItem -Path cert:\LocalMachine\root | Where-Object {$_.Thumbprint -eq $Thumbprint})
Set-VpnAuthProtocol -RootCertificateNameToAccept $RootCACert -PassThru

New-ItemProperty -Path ‘HKLM:\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\’ -Name CertAuthFlags -PropertyTYpe DWORD -Value ‘4’ -Force

Restart-Service RemoteAccess -PassThru

Always On VPN Device Tunnel and Certificate Revocation

A PowerShell script to update the RootCertificateNameToAccept parameter on multiple VPN servers can be found here.

Revoking Certificates

To prevent a Windows 10 Always On VPN device tunnel connection, the administrator must first revoke the certificate on the issuing CA. Next, open an elevated command window an enter the following commands. Repeat these steps on each VPN server in the enterprise.

certutil -urlcache * delete
certutil -setreg chain\ChainCacheResyncFiletime @now

Additional Information

Denying Access to Windows 10 Always On VPN Users or Computers

Blocking VPN Clients that use Revoked Certificates

PowerShell Script to Configure RootCertificateNameToAccept on GitHub

 

 

Always On VPN and the Future of Microsoft DirectAccess

Windows 10 Always On VPN hands-on training classes now forming. Details here.

Since the introduction of Windows Server 2012 in September of 2012, no new features or functionality have been added to DirectAccess. In Windows Server 2016, the only real change aside from bug fixes for DirectAccess is the removal of Network Access Protection (NAP) integration support.

Always On VPN and the Future of Microsoft DirectAccessFigure 1. Remote Access Setup wizard with NAP integration option in Windows Server 2012/R2.

Always On VPN and the Future of Microsoft DirectAccess

Figure 2. Remote Access Setup wizard without NAP integration option in Windows Server 2016.

DirectAccess Roadmap

It’s clear to see that Microsoft is no longer investing in DirectAccess, and in fact their field sales teams have been communicating this to customers for quite some time now. Microsoft has been actively encouraging organizations who are considering a DirectAccess solution to instead implement client-based VPN with Windows 10.

Always On VPN

New features introduced in the Windows 10 Anniversary Update allow IT administrators to configure automatic VPN connection profiles. This Always On VPN connection provides a DirectAccess-like experience using traditional remote access VPN protocols such as IKEv2, SSTP, and L2TP/IPsec. It comes with some additional benefits as well.

  • Conditional access and device compliance with system health checks
  • Windows Hello for Business and Azure multifactor authentication
  • Windows Information Protection (WIP) integration
  • Traffic filters to restrict VPN network access
  • Application-trigger VPN connections

DirectAccess Deprecated?

There has been rampant speculation that Microsoft plans to deprecate and retire DirectAccess. While that may in fact be true, Microsoft has yet to make a formal end-of-life announcement. There’s no reason DirectAccess and VPN couldn’t co-exist, so it’s not a certainty Microsoft will do this. However, there’s also no need to have multiple remote access solutions, and it is abundantly clear that the future for Microsoft remote access is Always On VPN and not DirectAccess.

Always On VPN and the Future of Microsoft DirectAccess

Source: https://social.technet.microsoft.com/wiki/contents/articles/38546.new-features-for-vpn-in-windows-10-and-windows-server-2016.aspx#Advanced_VPN_Connectivity

Always On VPN Advantages and Disadvantages

Windows 10 Always On VPN has some important advantages over DirectAccess. It has some crucial limitations as well.

Advantages

  • Always On VPN supports non-Enterprise Windows 10 client SKUs (Windows 10 Home and Professional)
  • Always On VPN includes support for granular network access control
  • Always On VPN can use both IPv4 and IPv6
  • Always On VPN is infrastructure independent. In addition to supporting Windows RRAS, any third-party network device can be used such as Cisco, Checkpoint, Juniper, Palo Alto, SonicWALL, Fortinet, and many more

Disadvantages

  • Always On VPN works only with Windows 10. It is not supported for Windows 7
  • Always On VPN cannot be managed natively using Active Directory and group policy. It must be configured and managed using Microsoft Intune. Alternatively, Microsoft System Center Configuration Manager (SCCM) or PowerShell can be used.

DirectAccess or Always On VPN?

Should you deploy DirectAccess today or implement Always On VPN with Windows 10 instead? That depends on a number of factors. It’s important to understand that DirectAccess will be fully supported through the lifecycle of Windows Server 2019. If DirectAccess meets your needs today, you can deploy it with confidence that it will still have a long support life. If you have reservations about the future viability of DirectAccess, and if you meet all of the requirements to support Always On VPN with Windows 10, then perhaps that’s a better choice. If you’d like to discuss your remote access options in more detail, fill out the form below and I’ll get in touch with you.

Additional Resources

5 Things DirectAccess Administrators Should Know About Always On VPN

3 Important Advantages of Always On VPN over DirectAccess

NetMotion Mobility as an Alternative to DirectAccess

Windows 10 Always On VPN Hands-On Training Classes

 

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.

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

A Windows 7 or Windows 8.x/10 client may fail to establish a DirectAccess connection using the IP-HTTPS IPv6 transition technology. When troubleshooting this issue, running ipconfig.exe shows that the media state for the tunnel adapter iphttpsinterface is Media disconnected.

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Running the Get-NetIPHttpsState PowerShell command on Windows 8.x/10 clients or the netsh interface httpstunnel show interface command on Windows 7 clients returns an error code of 0x90320, with an interface status Failed to connect to the IPHTTPS server; waiting to reconnect.

Troubleshooting DirectAccess IP-HTTPS Error Code 0x90320

Error code 0x90320 translates to SEC_I_INCOMPLETE_CREDENTIALS, indicating the client was unable to authenticate to the DirectAccess server during the TLS handshake when establishing the IP-HTTPS IPv6 transition tunnel. This occurs when the DirectAccess server or an Application Delivery Controller (ADC) is configured to perform client certificate authentication for IP-HTTPS connections. The client may fail to authenticate if it does not have a valid certificate issued by the organization’s internal certification authority (CA) or if the DirectAccess server or ADC is configured to perform IP-HTTPS client authentication incorrectly.

To resolve this issue, ensure that a valid certificate is installed on the DirectAccess client. In addition, ensure that the DirectAccess server or ADC is configured to use the correct CA when authenticating clients establishing IP-HTTPS connections.

Additional Information

DirectAccess IP-HTTPS Preauthentication 

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

DirectAccess SSL Offload and IP-HTTPS preauthentication using Citrix NetScaler 

DirectAccess IP-HTTPS preauthentication using F5 BIG-IP 

SSL Certificate Considerations for DirectAccess IP-HTTPS 

DirectAccess Now a Supported Workload in Microsoft Azure

DirectAccess Now a Supported Workload in Microsoft Azure

Important Update! Microsoft has recently reversed their decision to support DirectAccess in Microsoft Azure. The Microsoft Server Software Support for Microsoft Azure Vitual Machines document has once again been revised to indicate that DirectAccess is formally unsuported in Azure.

Update: Detailed guidance for deploying DirectAccess in Azure can be found here.

This is great news for organizations moving their infrastructure to the Microsoft Azure public cloud! Microsoft recently made some important changes to their published support statement for server software running on Azure virtual machines. Although no formal announcement was made, they quietly removed DirectAccess from the list of unsupported roles for Windows Server 2012 R2.

DirectAccess Now a Supported Workload in Microsoft Azure

I’ve performed some limited testing with DirectAccess using Resource Manager VMs in Microsoft Azure and it appears to be stable. In addition, some of the challenges I encountered previously when implementing DirectAccess in Azure using Classic VMs have now been resolved. I’ll be publishing some guidance for deploying DirectAccess in Azure soon.

Additional Resources

Deploying DirectAccess in Microsoft Azure
Implementing DirectAccess in Windows Server 2016
Fundamentals of Microsoft Azure 2nd Edition
Microsoft Azure Security Infrastructure
DirectAccess Multisite with Azure Traffic Manager

SSH Administration over a DirectAccess Connection

SSH Administration over a DirectAccess ConnectionFrom a client perspective, DirectAccess is an IPv6 only solution. All communication between the DirectAccess client and server takes place exclusively over IPv6. This can make things challenging for network engineers tasked with administering network devices using SSH over a DirectAccess connection. Often network devices don’t have corresponding hostname entries in DNS, and attempting to connect directly to an IPv4 address over a DirectAccess connection will fail.

To resolve this issue, it is necessary to create internal DNS records that resolve to IPv4 addresses for each network device. With that, the DNS64 service on the DirectAccess server will create an IPv6 address for the DirectAccess client to use. The NAT64 service will then translate this IPv6 address to IPv4 and connectivity will be established.

However, for many large organizations this might not be feasible. You may have hundreds or thousands of devices on your network to administer, and creating records in DNS for all these devices will take some time. As a temporary workaround, it is possible to determine the NAT64 IPv6 address for any network device and use that for remote network administration.

The process is simple. On a client that is connected remotely via DirectAccess, resolve the name of a known internal server to an IP address. The quickest and easiest way to do that is simply to ping an internal server by its hostname and note the IPv6 address it resolves to.

SSH Administration over a DirectAccess Connection

Now copy the first 96 bits of that address (everything up to and including the 7777::) and then append the IPv4 address of the network device you wish to manage in familiar dotted-decimal notation. The IPv6 address you create should look something like this:

fd74:45f9:4fae:7777::172.16.1.254

Enter this IPv6 address in whichever tool you use to manage your network devices and it should work. Here’s an example using the popular Putty tool connecting via SSH to a network device in my lab.

SSH Administration over a DirectAccess Connection

Figure 1 – DirectAccess Client IPv6 Prefix w/Appended IPv4 Address

SSH Administration over a DirectAccess Connection

Figure 2 – Successful connection over DirectAccess with Putty.

Going forward I would strongly recommend that you make it part of your normal production implementation process and procedures to create DNS records for all network devices. In the future you’ll absolutely have to do this for IPv6, so now is a good time to get in the habit of doing this. It will make your life a lot easier, trust me!

Please note that adding entries to the local HOSTS file of a DirectAccess client does not work! The name must be resolved by the DNS64 service on the DirectAccess server in order to work properly. Although you could populate the local HOSTS file with names and IPv6 addresses using the method I described above, it would cause problems when the client was on the internal network or connected remotely using traditional client-based VPN, so it is best to avoid using the HOSTS file altogether.

DirectAccess and Windows Server 2012 R2 Core

Important Note: The ability to switch back and forth between the full GUI and core versions of Windows was removed from Windows Server 2016. If you are deploying DirectAccess on Windows Server 2016, you must install server core initially. More details here.

DirectAccess and Windows Server 2012 R2 Core

Windows Server Core is an operating system configuration option that does not include a Graphical User Interface (GUI). Server Core was first introduced with Windows Server 2008 and originally included only a limited number of supported roles. With each subsequent release, Microsoft continues to add support for additional roles on Server Core. Beginning with Windows Server 2012, the Routing and Remote Access (RRAS) role, which includes DirectAccess, is a supported workload on Server Core.

Advantages of Server Core

There are a number of important advantages that come with running DirectAccess on Server Core. Server Core has a greatly reduced attack surface compared to the full GUI version, which is positive from a security perspective. Server Core also features a dramatically reduced footprint, consuming less RAM and disk space. System startup times are faster, and this refactored installation option also reduces servicing requirements (patching), eliminating many reboots and increasing availability and overall system uptime.

DirectAccess and Windows Server 2012 R2 Core

Figure 1 – Windows Server 2012 R2 Core Desktop (Yes, that’s it!)

Server Core Configuration

DirectAccess is a workload that lends itself well to running on Server Core, and I highly recommend leveraging this configuration whenever possible. Based on my experience, I suggest performing initial configuration and testing of the DirectAccess solution with the GUI installed, and then removing the GUI just before placing the DirectAccess server in to production. Removing the GUI can be accomplished by executing the following PowerShell command:

Remove-WindowsFeature Server-Gui-Mgmt-Infra –Restart

Once the server has been converted to Server Core, all administration must be performed at the command line on the server, or remotely from a management server or workstation using the command line or GUI administration tools. You can install the Remote Access Management console on any Windows Server 2012 R2 server using the following PowerShell command:

Install-WindowsFeature RSAT-RemoteAccess

Optionally you can download and install the Windows Server Remote Administrations Tools (RSAT) on a Windows client workstation, if desired.

Minimal Server Interface Configuration

If you prefer to be able to manage the DirectAccess server locally using the GUI, consider enabling the Minimal Server Interface. Minimal Server Interface is a configuration option that lies between Server Core and the full GUI interface. It features some of the benefits of Server Core, while at the same time providing local access to GUI management tools such as the Remote Access Management console. You can configure Minimal Server Interface using the following PowerShell command:

Remove-WindowsFeature Server-Gui-Shell -Restart

You can access the Remote Access Management console by entering RaMgmtUI.exe from the command line.

Revert to Full GUI

If at any point in the future you require the GUI for some reason, re-installing it can be accomplished using the following PowerShell command:

Install-WindowsFeature Server-Gui-Shell –Restart

Summary

With the Unified Remote Access role supported on Windows Server Core, consider implementing DirectAccess using this option to improve the security and increase the availability of your remote access solution. You’ll find that almost all ongoing server maintenance and support can be accomplished remotely using GUI tools, or locally using PowerShell. And if you ever need the GUI again, you can always add it back if necessary!

Additional Resources

DirectAccess on Windows Server 2016 Core

%d bloggers like this: