Always On VPN IKEv2 Security Configuration

Always On VPN IKEv2 Security ConfigurationWhen deploying Windows 10 Always On VPN, many administrators choose the Internet Key Exchange version 2 (IKEv2) protocol to provide the highest level of security and protection for remote connections. However, many do not realize the default security parameters for IKEv2 negotiated between a Windows Server running the Routing and Remote Access Service (RRAS) and a Windows 10 VPN client are far less than ideal from a security perspective. Additional configuration on both the server and the client will be required to ensure adequate security and protection for IKEv2 VPN connections.

Windows 10 and RRAS IKEv2 Defaults

In their default configuration, a Windows 10 client connecting to a Windows Server running RRAS will negotiate an IKEv2 VPN connection using the following IPsec security parameters.

  • Encryption: 3DES
  • Authentication/Integrity: SHA-1
  • Key Size: DH Group 2 (1024 bit)

This information can be obtained by opening an elevated PowerShell command window and running the following command.

Get-NetIPsecMainModeSA | Select-Object -First 1

Always On VPN IKEv2 Security Configuration

This can also be confirmed by viewing a network trace as shown here.

Always On VPN IKEv2 Security Configuration

These IPsec security parameters might have been acceptable in the 90’s, but they certainly are not today. 🙂

Improving IKEv2 Security

To provide a baseline level of protection to meet today’s requirements for security and privacy for IKEv2 VPN connections, the following are the minimum recommended IPsec security parameters.

  • Encryption: AES128
  • Authentication/Integrity: SHA-256
  • Key Size: DH Group 14 (2048 bit)

RRAS Custom IPsec Policy

To implement these recommended security baselines for IKEv2 on a Windows Server running RRAS it will be necessary to define a custom IPsec security policy. To do this, open an elevated PowerShell command window and run the following commands on each RRAS server.

Set-VpnServerConfiguration -CustomPolicy -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -SADataSizeForRenegotiationKilobytes 102400

Restart the Remote Access Management service for the changes to take effect.

Restart-Service RaMgmtSvc -PassThru

Always On VPN IKEv2 Security Configuration

Windows 10 Client Settings

The IPsec policy must match on both the server and the client for an IKEv2 VPN connection to be successful. Unfortunately, none of the IKEv2 IPsec security association parameters proposed by default on Windows 10 clients use 2048-bit keys (DH Group 14), so it will be necessary to define a custom IPsec security policy on the client to match the settings configured on the server.

To configure a matching IPsec security policy on an individual Windows 10 VPN client, open an elevated PowerShell command window and run the following command.

$connection = “[connection name]”
Set-VpnConnectionIPsecConfiguration -ConnectionName $connection -AuthenticationTransformConstants SHA256128 -CipherTransformConstants AES128 -DHGroup Group14 -EncryptionMethod AES128 -IntegrityCheckMethod SHA256 -PFSgroup PFS2048 -Force

Always On VPN IKEv2 Security Configuration

Restore Defaults

In the process of testing it may be necessary to restore the default IKEv2 configuration on both the client and the server. This can be accomplished by running the following PowerShell commands.

Server – Set-VpnServerConfiguration -RevertToDefault

Client – Set-VpnConnectionIPsecConfiguration -ConnectionName [connection_name] -RevertToDefault -Force

Always On VPN XML Settings

To implement a custom IPsec policy using the minimum recommended security settings for an Always On VPN connection using IKEv2, add the following settings to your ProfileXML.

<VPNProfile>
 <NativeProfile>
  <CryptographySuite>
   <AuthenticationTransformConstants>SHA256128</AuthenticationTransformConstants>
   <CipherTransformConstants>AES128</CipherTransformConstants>
   <EncryptionMethod>AES128</EncryptionMethod>
   <IntegrityCheckMethod>SHA256</IntegrityCheckMethod>
   <DHGroup>Group14</DHGroup>
   <PfsGroup>PFS2048</PfsGroup>
  </CryptographySuite>
 </NativeProfile>
</VPNProfile>

Why Not AES 256?

In the examples above you’ll notice that I’ve chosen to use AES128 and not AES256. This is by design, as AES256 does not provide any practical additional security in most use cases. Details here.

Enhanced Security and Performance

To further improve security and performance for IKEv2, consider implementing Elliptic Curve Cryptography (EC) certificates and using Galois Counter Mode (GCM) cipher suites such as GCMAES128 for authentication and encryption.

Additional Information

Always On VPN Certificate Requirements for IKEv2

Always On VPN IKEv2 Load Balancing with the KEMP LoadMaster Load Balancer

Always On VPN IKEv2 Load Balancing with KEMP LoadMaster

Always On VPN IKEv2 Load Balancing with KEMP LoadMasterIKEv2 is an IPsec-based VPN protocol with configurable security parameters that allows administrators to ensure the highest level of security for Windows 10 Always On VPN clients. It is the protocol of choice for deployments that require the best possible protection for communication between remote clients and the VPN server. IKEv2 has some unique requirements when it comes to load balancing, however. Because it uses UDP on multiple ports, configuring the load balancer requires some additional steps for proper operation. This article demonstrates how to enable IKEv2 load balancing using the KEMP LoadMaster load balancer.

IKEv2 and NAT

IKEv2 VPN security associations (SAs) begin with a connection to the VPN server that uses UDP port 500. During this initial exchange, if it is determined that the client, server, or both are behind a device performing Network Address Translation (NAT), the connection switches to UDP port 4500 and the connection establishment process continues.

IKEv2 Load Balancing Challenges

Since UDP is connectionless, there’s no guarantee that when the conversation switches from UDP 500 to UDP 4500 that the load balancer will forward the request to the same VPN server on the back end. If the load balancer forwards the UDP 500 session from a VPN client to one real server, then forwards the UDP 4500 session to a different VPN server, the connection will fail. The load balancer must be configured to ensure that both UDP 500 and 4500 from the same VPN client are always forwarded to the same real server to ensure proper operation.

Port Following

To meet this unique requirement for IKEv2 load balancing, it is necessary to use a feature on the KEMP LoadMaster load balancer called “port following”. Enabling this feature will ensure that a VPN client using IKEv2 will always have their UDP 500 and 4500 sessions forwarded to the same real server.

Load Balancing IKEv2

Open the web-based management console and perform the following steps to enable load balancing of IKEv2 traffic on the KEMP LoadMaster load balancer.

Create the Virtual Server

  1. Expand Virtual Services.
  2. Click Add New.
  3. Enter the IP address to be used by the virtual server in the Virtual Address field.
  4. Enter 500 in the Port field.
  5. Select UDP from the Protocol drop-down list.
  6. Click Add this Virtual Service.

Always On VPN IKEv2 Load Balancing with KEMP LoadMaster

Add Real Servers

  1. Expand Real Servers.
  2. Click Add New.
  3. Enter the IP address of the VPN server in the Real Server Address field.
  4. Click Add This Real Server.
  5. Repeat the steps above for each VPN server in the cluster.

Always On VPN IKEv2 Load Balancing with KEMP LoadMaster

Repeat all the steps above to create another virtual server using UDP port 4500.

Always On VPN IKEv2 Load Balancing with KEMP LoadMaster

Enable Layer 7 Operation

  1. Click View/Modify Services below Virtual Services in the navigation tree.
  2. Select the first virtual server and click Modify.
  3. Expand Standard Options.
  4. Uncheck Force L4.
  5. Select Source IP Address from the Persistence Options drop-down list.
  6. Choose an appropriate value from the Timeout drop-down list.
  7. Choose an appropriate setting from the Scheduling Method drop-down list.
  8. Click Back.
  9. Repeat these steps on the second virtual server.

Always On VPN IKEv2 Load Balancing with KEMP LoadMaster

Enable Port Following

  1. Click View/Modify Services below Virtual Services in the navigation tree.
  2. Select the first virtual server and click Modify.
  3. Expand Advanced Properties.
  4. Select the virtual server using UDP 500 from the Port Following drop-down list.
  5. Click Back.
  6. Repeat these steps on the second virtual server.

Always On VPN IKEv2 Load Balancing with KEMP LoadMaster

Demonstration Video

The following video demonstrates how to enable IKEv2 load balancing for Windows 10 Always On VPN using the KEMP LoadMaster Load Balancer.

Summary

With the KEMP LoadMaster load balancer configured to use port following, Windows 10 Always On VPN clients using IKEv2 will be assured that their connections will always be delivered to the same back end VPN server, resulting in reliable load balancing for IKEv2 connections.

Additional Information

Windows 10 Always On VPN Certificate Requirements for IKEv2

Windows 10 Always On VPN Protocol Recommendations for Windows Server RRAS

What is the Difference Between DirectAccess and Always On VPN?

Always On VPN Device Tunnel Configuration Guidance Now AvailableDirectAccess has been around for many years, and with Microsoft now moving in the direction of Always On VPN, I’m often asked “What’s the difference between DirectAccess and Always On VPN?” Fundamentally they both provide seamless and transparent, always on remote access. However, Always On VPN has a number of advantages over DirectAccess in terms of security, authentication and management, performance, and supportability.

Security

DirectAccess provides full network connectivity when a client is connected remotely. It lacks any native features to control access on a granular basis. It is possible to restrict access to internal resources by placing a firewall between the DirectAccess server and the LAN, but the policy would apply to all connected clients.

Windows 10 Always On VPN includes support for granular traffic filtering. Where DirectAccess provides access to all internal resources when connected, Always On VPN allows administrators to restrict client access to internal resources in a variety of ways. In addition, traffic filter policies can be applied on a per-user or group basis. For example, users in accounting can be granted access only to their department servers. The same could be done for HR, finance, IT, and others.

Authentication and Management

DirectAccess includes support for strong user authentication with smart cards and one-time password (OTP) solutions. However, there is no provision to grant access based on device configuration or health, as that feature was removed in Windows Server 2016 and Windows 10. In addition, DirectAccess requires that clients and servers be joined to a domain, as all configuration settings are managed using Active Directory group policy.

Windows 10 Always On VPN includes support for modern authentication and management, which results in better overall security. Always On VPN clients can be joined to an Azure Active Directory and conditional access can also be enabled. Modern authentication support using Azure MFA and Windows Hello for Business is also supported. Always On VPN is managed using Mobile Device Management (MDM) solutions such as Microsoft Intune.

Performance

DirectAccess uses IPsec with IPv6, which must be encapsulated in TLS to be routed over the public IPv4 Internet. IPv6 traffic is then translated to IPv4 on the DirectAccess server. DirectAccess performance is often acceptable when clients have reliable, high quality Internet connections. However, if connection quality is fair to poor, the high protocol overhead of DirectAccess with its multiple layers of encapsulation and translation often yields poor performance.

The protocol of choice for Windows 10 Always On VPN deployments is IKEv2. It offers the best security and performance when compared to TLS-based protocols. In addition, Always On VPN does not rely exclusively on IPv6 as DirectAccess does. This reduces the many layers of encapsulation and eliminates the need for complex IPv6 transition and translation technologies, further improving performance over DirectAccess.

Supportability

DirectAccess is a Microsoft-proprietary solution that must be deployed using Windows Server and Active Directory. It also requires a Network Location Server (NLS) for clients to determine if they are inside or outside the network. NLS availability is crucial and ensuring that it is always reachable by internal clients can pose challenges, especially in very large organizations.

Windows 10 Always On VPN supporting infrastructure is much less complex than DirectAccess. There’s no requirement for a NLS, which means fewer servers to provision, manage, and monitor. In addition, Always On VPN is completely infrastructure independent and can be deployed using third-party VPN servers such as Cisco, Checkpoint, SonicWALL, Palo Alto, and more.

Summary

Windows 10 Always On VPN is the way of the future. It provides better overall security than DirectAccess, it performs better, and it is easier to manage and support.

Here’s a quick summary of some important aspects of VPN, DirectAccess, and Windows 10 Always On VPN.

Traditional VPN DirectAccess Always On VPN
Seamless and Transparent No Yes Yes
Automatic Connection Options None Always on Always on, app triggered
Protocol Support IPv4 and IPv6 IPv6 Only IPv4 and IPv6
Traffic Filtering No No Yes
Azure AD Integration No No Yes
Modern Management Yes No (group policy only) Yes (MDM)
Clients must be domain-joined? No Yes No
Requires Microsoft Infrastructure No Yes No
Supports Windows 7 Yes Yes Windows 10 only

Always On VPN Hands-On Training

If you are interested in learning more about Windows 10 Always On VPN, consider registering for one of my hands-on training classes. More details here.

Additional Resources

Always On VPN and the Future of Microsoft DirectAccess

5 Important Things DirectAccess Administrators Should Know about Windows 10 Always On VPN

3 Important Advantages of Windows 10 Always On VPN over DirectAccess

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

Always On VPN Protocol Recommendations for Windows Server Routing and Remote Access Service (RRAS)Windows 10 Always On VPN is infrastructure independent and can be implemented using third-party VPN devices. It is not necessary to deploy any Windows servers at all to support an Always On VPN solution. However, in a recent blog post I outlined some compelling reasons to consider using Windows Server 2016’s Routing and Remote Access Service (RRAS) feature to terminate VPN connections. RRAS supports both modern and legacy VPN protocols, each with their own advantages and disadvantages. The choice of which protocols to support will be determined by many factors, but it is important to understand the capabilities of each to make an informed decision.

RRAS VPN Protocols

Windows RRAS supports the following VPN protocols.

  • Internet Key Exchange version 2 (IKEv2) – RFC7296
  • Secure Sockets Tunneling Protocol (SSTP) – Microsoft
  • Layer Two Tunneling Protocol over IPsec (L2TP/IPsec) – RFC2661
  • Point-to-Point Tunneling Protocol (PPTP) – RFC2637

There are pros and cons associated with each of these VPN protocols. Here’s a breakdown of each.

IKEv2

This IPsec-based VPN protocol is the preferred choice for most deployments. IKEv2 provides the best security and performance, with native features that enhance mobility. This latest version of IKE (v2) features streamlined messaging during connection establishment and enhanced session management that reduce protocol overhead and improve performance.

Advantages: Best security and performance.
Disadvantages: Firewalls may block required UDP ports.

SSTP

SSTP is an excellent alternative to IKEv2. It uses industry standard Transport Layer Security (TLS), making it widely accessible from most locations. It provides good security out of the box, but can be improved upon with additional configuration. SSTP lends itself well to load balancing, making it much easier to scale out than IKEv2. Optionally, TLS can be offloaded to an Application Delivery Controller (ADC) to reduce resource utilization on the RRAS server and further improve performance.

Advantages: Easy to configure with firewall friendly access.
Disadvantages: Not as secure IKEv2.

L2TP

While technically supported for Always On VPN, L2TP is a legacy VPN protocol that offers no real advantages over IKEv2. Its use is unnecessary and should be avoided.

Advantages: None.
Disadvantages: Firewalls may block required UDP ports.

PPTP

PPTP is considered an obsolete VPN protocol with many known security vulnerabilities. Its use should be avoided at all costs.

Advantages: None.
Disadvantages: Insecure.

Summary

Implementation best practices dictate that IKEv2 and SSTP be enabled to support Windows 10 Always On VPN connections when using Windows Server 2016 RRAS. The use of L2TP/IPsec and PPTP should be avoided. The combination of IKEv2 and SSTP will provide the best security and availability for remote workers. Clients that can establish IKEv2 VPN connections can take advantages of the security and performance benefits it provides. SSTP can be enabled as a fallback for clients that are unable to establish an IKEv2 connection due to restricted firewall access.

Always On VPN Hands-On Training

Interested in learning more about Windows 10 Always On VPN? Hands-on training classes are now forming. More details here.

Additional Resources

Frequently Asked Questions about Microsoft’s PPTP Implementation

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

Windows 10 Always On VPN and the Future of DirectAccess 

5 Things DirectAccess Administrators Should Know about Always On VPN 

3 Important Advantages of Windows 10 Always On VPN over DirectAccess 

Windows 10 Always On VPN Hands-On Training Classes

5 Things DirectAccess Administrators Should Know About Always On VPN

5 Things DirectAccess Administrators Should Know About Always On VPNWindows 10 Always On VPN hands-on training classes now forming. Details here.

As I’ve written about previously, Microsoft is no longer investing in DirectAccess going forward. There will be no new features or functionality added to the product in the future. Microsoft is now investing in Always On VPN in Windows 10, with new features being released with each semi-annual update of the operating system. But as Microsoft continues to make the push toward Always On VPN over DirectAccess, many administrators have asked about the ramifications of this shift in focus for enterprise remote access. Here are a few points to consider.

It’s the same thing, only different.

Always On VPN provides the same seamless, transparent, always on experience as DirectAccess. Under the covers, the mechanics of how that’s accomplished changes a bit, but fundamentally the user experience is exactly the same. Once a user logs on to their device, a VPN connection is established automatically and the user will have secure remote access to corporate resources.

The connection is still secure.

Where DirectAccess uses IPsec and Connection Security Rules (CSRs) to establish its secure tunnels, Always On VPN uses traditional client-based VPN protocols such as IKEv2, SSTP, L2TP, and PPTP. Both DirectAccess and Always On VPN use certificates for authentication. However, where DirectAccess uses machine certificates to authenticate the computer, Always On VPN leverages user certificates to authenticate the user.

(Note: Machine certificates will be required for Always On VPN when using the optional device tunnel configuration. I will publish more details about this configuration option in a future article.)

Provisioning and managing clients is different.

The administrative experience for Always On VPN is much different than it is with DirectAccess. Where DirectAccess made use of Active Directory and group policy for managing client and server settings, Always On VPN clients must be provisioned using a Mobile Device Management (MDM) solution such as Microsoft Intune, or any third-party MDM platform. Optionally, Always On VPN clients can be provisioned using Microsoft System Center Configuration Manager (SCCM), or manually using PowerShell.

Security is enhanced.

Always On VPN has the potential to provide much more security and protection than DirectAccess. Always On VPN supports traffic filtering, allowing administrators to restrict remote client communication by IP address, protocol, port, or application. By contrast, DirectAccess allows full access to the internal network after user logon with no native capability to restrict access. In addition, Always On VPN supports integration with Azure Active Directory, which enables conditional access and multifactor authentication scenarios.

It’s built for the future.

Always On VPN also provides support for modern authentication mechanisms like Windows Hello for Business. In addition, Windows Information Protection (WIP) integration is supported to provide essential protection for enterprise data.

Summary

Microsoft set the bar pretty high with DirectAccess. Users love the seamless and transparent access it provides, and administrators reap the benefit of improved systems management for field based devices. Always On VPN provides those same benefits, with additional improvements in security and protection. If you’d like more information about Always On VPN, fill out the form below and I’ll get in touch with you.

Additional Information

Always On VPN and the Future of DirectAccess

3 Important Advantages of Windows 10 Always On VPN over Microsoft DirectAccess

Windows 10 Always On VPN Hands-On Training

Top 5 DirectAccess Troubleshooting PowerShell Commands

Top 5 DirectAccess Troubleshooting PowerShell CommandsNative PowerShell commands in Windows 10 make DirectAccess troubleshooting much easier than older operating systems like Windows 7. For example, with one PowerShell command an administrator can quickly determine if a DirectAccess client has received the DirectAccess client settings policy. In addition, PowerShell can be used to view the status of the connection and retrieve additional information or error codes that can be helpful for determining the cause of a failed connection. Further, PowerShell can also be used to review configuration details and perform other troubleshooting and connectivity validation tasks.

Here are my top 5 PowerShell commands for troubleshooting DirectAccess on Windows 10.

1. Get-DAClientExperienceConfiguration

Ensuring that the DirectAccess Client Settings group policy has been applied to the client is one of the first steps in troubleshooting failed DirectAccess connections. While it is possible to use gpresult to do this, using the Get-DAClientExperienceConfiguration PowerShell command is much simpler. If DirectAccess client settings have been applied, the output of the command will include information such as the IPsec tunnel endpoint IPv6 addresses and the Network Connectivity Assistant (NCA) corporate resource URL. If DirectAccess client settings have not been applied, this information will be missing.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 1. DirectAccess Client Settings group policy successfully applied.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 2. DirectAccess Client Settings group policy not applied.

2. Get-NetIPHttpsState

Performance improvements first introduced in Windows 8 have made IP-HTTPS the IPv6 transition technology of choice when it comes to supporting DirectAccess client connectivity. Also, if the DirectAccess server is located behind an edge device performing Network Address Translation (NAT), IP-HTTPS is the only supported transition technology. Using the Get-NetIPHttpsState PowerShell command, the DirectAccess administrator can quickly determine if the IP-HTTPS connection was successful. If it was not, the command will return an error code and interface status that will indicate why the IP-HTTPS connection was unsuccessful.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 3. Get-NetIPHttpsState

3. Get-NetIPHttpsConfiguration

When troubleshooting IP-HTTPS connection failures, it is necessary to obtain additional information to continue the troubleshooting process. Using the Get-NetIPHttpsConfiguration PowerShell command, the DirectAccess administrator can obtain the public hostname for the DirectAccess server and ensure that the name resolves to the correct IP address in DNS and that it is reachable on TCP port 443.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 4. Get-NetIPHttpsConfiguration

4. Resolve-DnsName

Using the Resolve-DnsName PowerShell command is crucial when performing any name resolution tasks on the DirectAccess client. This is because Resolve-DnsName is aware of the Name Resolution Policy Table (NRPT) and will direct name resolution requests accordingly. Tools like nslookup are DNS server testing tools and are unaware of the NRPT. Typically they do not yield expected results when testing name resolution on a DirectAccess client.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 5. Name resolution results from Resolve-DnsName and nslookup.

5. Get-DnsClientNrptPolicy

Often the cause of DirectAccess client connectivity issues is a misconfigured NRPT. Using the Get-DnsClientNrptPolicy PowerShell command the DirectAccess administrator can validate that name resolution requests for host names in any internal namespaces are being sent to the DirectAccess DNS64 IPv6 address.

Top 5 DirectAccess Troubleshooting PowerShell Commands

Figure 6. Get-DnsClientNrptPolicy

Additional Resources

Top 5 DirectAccess Troubleshooting Tips

Troubleshooting Name Resolution Issues on DirectAccess Clients

Learn PowerShell in a Month of Lunches Book by Don Jones and Jeff Hicks

Implementing DirectAccess with Windows Server 2016 Book

Planning and Implementing DirectAccess with Windows Server 2016 Video Training Course

Managing and Supporting DirectAccess with Windows Server 2016 Video Training Course

 

 

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.

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

Note: For information about configuring the Citrix NetScaler to perform IP-HTTPS preauthentication, click here. For information about configuring Windows Server 2012 R2 to perform IP-HTTPS preauthentication natively, click here.

Introduction

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IPRecently I wrote about security challenges with DirectAccess and the IP-HTTPS IPv6 transition technology. Specifically, IP-HTTPS transition tunnel connections are not authenticated by the DirectAccess server, only the client. This allows an unauthorized device to obtain an IPv6 address on the DirectAccess client network. With it, an attacker can perform network reconnaissance using ICMPv6 and potentially launch a variety of Denial-of-Service (DoS) attacks. For more details, click here.

Note: DirectAccess IPsec data connections not at risk. Data is never exposed at any time with the default configuration.

Mitigation

To mitigate these issues, it is recommended that an Application Delivery Controller (ADC) be used to terminate SSL connections and enforce client certificate authentication. Doing this will ensure that only authorized connections will be accepted by the DirectAccess server. In addition, there are some scalability and performance benefits to implementing this configuration when supporting Windows 7 clients.

Important Considerations

Performing IP-HTTPS preauthentication on the F5 BIG-IP is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the F5 appliance breaks OTP authentication.

F5 BIG-IP Configuration

To configure the F5 BIG-IP to perform SSL offload for DirectAccess IP-HTTPS, follow the guidance documented here. In addition, to configure the F5 BIG-IP to perform preauthentication for DirectAccess clients, when creating the client SSL profile, click Custom above the Client Authentication section and choose Require from the Client Certificate drop-down list and Always from the Frequency drop-down list. In addition, choose your internal PKI’s root Certification Authority (CA) certificate from the Trusted Certificate Authorities drop-down list and from the Advertised Certificate Authorities drop-down list.

DirectAccess IP-HTTPS Preauthentication using F5 BIG-IP

Summary

Enabling client certificate authentication for IP-HTTPS connections ensures that only authorized DirectAccess clients can establish a connection to the DirectAccess server and obtain an IPv6 address. It also prevents an unauthorized user from performing network reconnaissance or launching IPv6 Denial-of-Service (DoS) attacks.

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

Note: For information about configuring the F5 BIG-IP to perform IP-HTTPS preauthentication, click hereFor information about configuring Windows Server 2012 R2 or Windows Server 2016 to perform IP-HTTPS preauthentication natively, click here.

Introduction

DirectAccess IP-HTTPS Preauthentication using Citrix NetScalerIP-HTTPS is an IPv6 transition technology used by DirectAccess. It enables DirectAccess clients to communicate with the DirectAccess server using IPv6 over the public IPv4 Internet by encapsulating IPv6 packets in HTTP and authenticating (and optionally encrypting) them using SSL/TLS. IP-HTTPS is supported for all DirectAccess network deployment configurations and is enabled by default.

When a DirectAccess client connection is established, only the server is authenticated by the client. The client is not authenticated by the server. The DirectAccess server will thus accept IP-HTTPS connections from any client, valid or not.

IP-HTTPS Connection

Once a client has established an IP-HTTPS transition tunnel, it will go through the standard IPv6 neighbor discovery process to identify routers and obtain an IPv6 prefix for the link. It will use this information to build its own IPv6 address, which it uses to communicate with the DirectAccess server and begin establishing IPsec security associations for DirectAccess.

ICMP and IPsec

By design, ICMP is exempt from DirectAccess IPsec policy processing. If an unauthorized client were to establish an IP-HTTPS transition tunnel, even without authentication (Kerberos Proxy or certificate) it would be able to ping the DirectAccess server tunnel endpoint IPv6 addresses, the DNS64 IPv6 address, and any intranet hosts (assuming host firewalls allow this access).

Security Risk

This default posture opens up the DirectAccess server and intranet to unauthorized remote network reconnaissance and some IPv6-related Denial-of-Service (DoS) attacks. These were demonstrated by security researcher Ali Hardudi at the recent Troopers16 security conference. You can view his very informative session here.

Note: DirectAccess IPsec data connections are unaffected and are completely secure. Data is never exposed at any time with the default configuration.

IP-HTTPS Preauthentication

DirectAccess IP-HTTPS Preauthentication using Citrix NetScalerTo mitigate these risks, it is recommended that an Application Delivery Controller (ADC) such as the Citrix NetScaler be configured to preauthenticate DirectAccess clients prior to establishing the IP-HTTPS transition tunnel.

Note: To configure the F5 BIG-IP to perform IP-HTTPS preauthentication, click here.

Citrix NetScaler Configuration

To perform DirectAccess preauthentication, it will be necessary to configure the Citrix NetScaler to perform SSL termination for IP-HTTPS. The virtual server on the NetScaler must use the SSL protocol. In addition, a CA certificate must be bound to the virtual server. Also, Client Authentication must be enabled under SSL Parameters and be set to Mandatory.

DirectAccess IP-HTTPS Preauthentication using Citrix NetScaler

Once configured, the NetScaler appliance will ensure that the DirectAccess IPsec certificate is present on the client before establishing the IP-HTTPS IPv6 transition tunnel. This will prevent unauthorized connections to the DirectAccess server.

Important Considerations

Performing IP-HTTPS preauthentication on the Citrix NetScaler is formally unsupported by Microsoft. In addition, terminating IP-HTTPS on the NetScaler appliance breaks OTP authentication.

Summary

The default security posture of DirectAccess leaves the internal network open to unauthorized network reconnaissance, and exposes the DirectAccess infrastructure to potential denial-of-service (DoS) attacks. To mitigate these security risks, implement the Citrix NetScaler ADC and enable client certificate authentication.

References

Security Assessment of Microsoft DirectAccess [Overview] – https://www.insinuator.net/2016/04/security-assessment-of-microsoft-directaccess/

Security Assessment of Microsoft DirectAccess [Full Document] – https://www.ernw.de/newsfeed/newsletter-53-may-2016-security-assessment-of-microsoft-directaccess/index.html

Security Assessment of Microsoft DirectAccess Troopers16 Presentation by Ali Hardudi [Video] – https://www.youtube.com/watch?v=wW1x7ow0V9w

Chiron IPv6 Penetration Testing Framework – https://www.insinuator.net/2014/10/chiron-an-all-in-one-ipv6-penetration-testing-framework/

IP-HTTPS specification on MSDN – https://msdn.microsoft.com/en-us/library/dd358571.aspx

Configure F5 BIG-IP to Perform IP-HTTPS Preauthentication – https://directaccess.richardhicks.com/2016/05/23/directaccess-ip-https-preauthentication-using-f5-big-ip/

Configure Windows Server 2012 R2  and Windows Server 2016 to Perform IP-HTTPS Preauthentication – https://directaccess.richardhicks.com/2016/06/13/directaccess-ip-https-preauthentication/

ISP Address Field is Blank in DirectAccess Status and Reports

When viewing DirectAccess client status in the Remote Access Management console, you will notice that the ISP address field is blank for clients using the IP-HTTPS IPv6 transition protocol. However, the ISP Address information is displayed for clients using the 6to4 or Teredo IPv6 transition protocols.

ISP Address Field is Blank in DirectAccess Status and Reports

This is expected behavior and occurs as a result of the way in which the DirectAccess reports obtain the client’s public ISP address information. The ISP address is derived from the IPv6 address used to establish the DirectAccess client’s IPsec Security Associations (SAs) on the DirectAccess server. For clients using the 6to4 or Teredo IPv6 transition protocols, the client’s public IPv4 address is embedded in its IPv6 address. This information is displayed in the ISP Address field. However, the IP-HTTPS IPv6 transition protocol uses completely random IPv6 addresses. Without an embedded IPv4 address, the Remote Access Management console lacks the information to display in the ISP Address field.

Updated 3/22/2015: With a little extra work it is possible to find the IPv4 ISP address for DirectAccess clients using the IP-HTTPS IPv6 transition protocol. For more information, please refer to Microsoft PFE Martin Solis’ excellent blog post on the subject here.

%d bloggers like this: