DirectAccess IPv6 Transition Protocols Explained

Introduction

From a client perspective, DirectAccess is an IPv6-only solution. The DirectAccess client communicates with the DirectAccess server exclusively using IPv6. However, IPv6 is not widely deployed, so the most common scenario will find your DirectAccess clients and servers on the IPv4 Internet.

To facilitate DirectAccess client to server communication with IPv6 when the client is on the IPv4 Internet, IPv6 transition protocols are employed. These protocols effectively tunnel IPv6 packets in IPv4 packets. DirectAccess makes use of three IPv6 transition protocols for client to server connections – 6to4, Teredo, and IP-HTTPS.

DirectAccess Transition Protocols

6to4 – The 6to4 IPv6 transition protocol works by encapsulating IPv6 packets in IPv4 packets using IP protocol 41. 6to4 does not work when the client or the server is behind a NAT, so this IPv6 transition protocol is only used when the client and server are assigned public IPv4 addresses. DirectAccess clients with public IPv4 addresses aren’t common though, and there are some challenges with the stability of 6to4. From experience I can tell you that 6to4 often fails when clients use a cellular Wi-Fi hotspot, for example. For this reason it is generally recommended that you proactively disable this transition protocol to avoid potential issues in the future.

TeredoTeredo is an IPv6 transition protocol that is designed to work when a DirectAccess client (but not the DirectAccess server) is behind a NAT. It works by encapsulating IPv6 packets in IPv4 packets using UDP on port 3544. Teredo will be used any time the DirectAccess client has a private IPv4 address, or when the client has a public IPv4 address and the 6to4 protocol is unavailable (e.g. 6to4 is disabled, or outbound access to IP protocol 41 is restricted by firewall policy). To support Teredo, the DirectAccess server must be configured with two consecutive public IPv4 addresses. In addition, Teredo uses ICMP for NAT detection (e.g. cone, restricted, symmetric), so ICMPv4 echo requests must be allowed inbound to any host with which the DirectAccess client communicates.

IP-HTTPSIP-HTTPS is an IPv6 transition protocol that works by encapsulating IPv6 packets in IPv4 packets using HTTP with SSL/TLS. It is the IPv6 transition protocol of last resort, and will be used any time that 6to4 or Teredo aren’t available. The advantage to using IP-HTTPS is ubiquitous firewall access. Any network with access to the public Internet should, at a minimum, allow outbound HTTP and HTTPS. In some deployment scenarios, IP-HTTPS can be disadvantageous. For example, when Windows 7 DirectAccess clients leverage this IPv6 transition protocol, IPsec-encrypted traffic is encrypted again using SSL/TLS. This double encryption results in high processing overhead and often translates to poor performance and limited scalability. Windows 8 and later clients do not suffer this limitation, as they support null encryption which eliminates the negative effects imposed by double encryption. For the best results using IP-HTTPS, use an application delivery controller to offload SSL, or deploy Windows 8 or later clients. In any case, do not collocate the client-based VPN role on the DirectAccess server, as doing so will remove support for null encryption completely and force even Windows 8 and later clients to perform double encryption for IP-HTTPS traffic.

DirectAccess Server Configuration

To support the 6to4 and Teredo IPv6 transition protocols, the DirectAccess server must be configured with two network interfaces; one internal and one external. The DirectAccess server must have public IPv4 addresses assigned to its external network interface. For Teredo in particular, the DirectAccess server requires two consecutive public IPv4 addresses. Beginning with Windows Server 2012, DirectAccess provides support for DMZ/perimeter network deployment behind a NAT device using RFC1918 private IPv4 addresses with either one or two network interfaces. In this deployment scenario, the DirectAccess server only supports the use of the IP-HTTPS IPv6 transition protocol. 6to4 and Teredo are not available when the DirectAccess server is located behind a NAT device and these IPv6 transition protocols should be disabled on all DirectAccess clients.

POODLE and DirectAccess

Recently a new and very serious vulnerability in the SSL 3.0 protocol has been discovered that allows an attacker to recover sensitive information for an encrypted session. As DirectAccess uses SSL and TLS as part of the IP-HTTPS IPv6 transition protocol, I’ve had many customers ask me about mitigating this vulnerability on a DirectAccess server.

POODLE and DirectAccess

Figure 1 – Qualys SSL Labs Server Test Score for DirectAccess IP-HTTPS

However, is mitigating the POODLE attack on a DirectAccess server really necessary? Recall that, as I’ve discussed previously, the IP-HTTPS IPv6 transition protocol is only used to tunnel IPv6 traffic from the DirectAccess client to the DirectAccess server over the public IPv4 Internet. This traffic is already encrypted with IPsec, so there’s really nothing an attacker would gain by leveraging the POODLE attack on a DirectAccess session.

The recommended mitigation for the POODLE attack is to disable the use of SSL 3.0 on servers and clients. If you have deployed DirectAccess by itself, there’s no need to implement this mitigation as there is no real risk associated with this attack in this specific scenario. However, there are no negative side effects for doing so, and if you wish to disable SSL 3.0 just to avoid future audit findings, I see no problem with that.

If your DirectAccess server is also configured to support client-based VPN and you’ve enabled the Secure Sockets Tunneling Protocol (SSTP) then mitigating the POODLE attack is an excellent idea. SSTP also uses SSL and TLS, so this session could be hijacked by an attacker and sensitive information might be disclosed.

To disable SSL 3.0 on the DirectAccess server, execute the following commands from an elevated PowerShell window.

New-Item -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" -Force
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Server" -PropertyType dword -Value 0 -Name Enabled

A restart of the server is required for the changes to take effect. To audit your DirectAccess server’s SSL and TLS configuration, visit the Qualys SSL Labs server test site. For more information about the POODLE SSL 3.0 vulnerability, click here.