With the August security update release cycle, Microsoft issued security bulletin MS13-064 to address a vulnerability in the Windows NAT driver that could result in a denial of service. The vulnerability could be exploited by an attacker who sends a specially crafted ICMP packet to the server running the Windows NAT Driver service. The vulnerability exists only on Windows Server 2012 and the affected driver, winnat.sys, is present when the DirectAccess role is installed. This vulnerability only affects only full installations of Windows Server 2012. Windows Server 2012 Core is not affected. If you are running DirectAccess on a full installation of Windows Server 2012, make sure you install this update as soon as possible to be protected from potential denial of service attacks. For more information about this update, click here. For a comprehensive list of updates that apply to DirectAccess on Windows Server 2012 as well as previous versions, please refer to Jason Jones’ DirectAccess hotfix summary page.
Posted by Richard M. Hicks on August 20, 2013
One of the more common barriers to adoption for DirectAccess in Windows Server 2008 R2 and Forefront Unified Access Gateway (UAG) 2010 is the strict requirement for two consecutive public IPv4 addresses to be assigned to the external network interface of the DirectAccess server. Many small and mid-sized businesses have only a single public IPv4 address, or have a very small range of public IPv4 addresses that are already in use. For large organizations, corporate security policies often dictate that Windows-based systems cannot be internet facing, and many object to having a domain-joined Windows system exposed directly to the Internet. Further complicating matters is the fact that deploying a Window Server 2008 R2 or Forefront UAG 2010 DirectAccess server behind a border router or edge firewall performing Network Address Translation (NAT) is explicitly not supported.
Beginning with Windows Server 2012, deploying the DirectAccess server behind a border router or edge firewall performing NAT is now fully supported. No longer is there a requirement to have public IPv4 addresses assigned to the DirectAccess server’s external network interface. In fact, DirectAccess in Windows Server 2012 can be deployed with a single network adapter, allowing the DirectAccess server to be completely isolated in a perimeter or DMZ network.
Be advised that deploying a Windows Server 2012 DirectAccess server behind a NAT device will result in all DirectAccess client communication being delivered to the server exclusively using the IP-HTTPS IPv6 transition protocol. If you are using Windows 8 clients, there’s nothing to worry about in terms of performance and scalability because Windows 8 clients leverage NULL encryption for IP-HTTPS traffic. However, Windows 7 clients cannot utilize NULL encryption and will instead encrypt all DirectAccess client communication using SSL/TLS. DirectAccess communication is already encrypted using IPsec, so this presents a problem. Double encryption places high demands on the DirectAccess server’s CPU and memory and will significantly impact performance on the client and the server. It will also impede the scalability of the solution by dramatically reducing the number of DirectAccess clients supported on a single DirectAccess server.
So, if you’re planning to deploy a Windows Server 2012 DirectAccess server behind a NAT, and you are also planning to support a lot of Windows 7 clients, please proceed cautiously. Monitor the DirectAccess server performance closely during your pilot and, if at all possible, offload SSL/TLS off box using F5 BIG-IP Local Traffic Manager (LTM) or equivalent device.
Posted by Richard M. Hicks on March 19, 2013
IPv6 is one of the main underpinnings of DirectAccess. All communication between the DirectAccess client and the DirectAccess server and corporate network resources takes place using IPv6 only. DNS64 and NAT64, the protocol translators for DNS and NAT, address these concerns by translating native IPv6 traffic to IPv4, allowing the DirectAccess client to communicate with systems on the corporate network that are running only IPv4. This significantly reduces the barrier to entry for the adoption of DirectAccess as a remote access solution, but it doesn’t eliminate the requirement for IPv6 altogether. When DNS64 and NAT64 are leveraged, either as part of UAG DirectAccess or the unified remote access role in Windows Server 2012, it is important to remember that the DirectAccess client still communicates with the DirectAccess server using IPv6. It is for this reason that I strongly recommend and encourage systems and network engineers to start learning IPv6 today! I realize that IPv6 looks a bit scary from the outside. The address space is 128-bit and IPv6 addresses are written in hexadecimal, which can be quite daunting for many, me included. There are some new acronyms to learn as well. However, do you recall a time when you didn’t know IPv4? I certainly do! I remember first learning it and thinking I would never get it. Subnet masks? Dotted decimal notation? CIDR? They were completely foreign concepts. Eventually you learn it, gain experience deploying and troubleshooting it, and soon thereafter it becomes second nature. That is most people’s experience with IPv4, and it will be no different with IPv6. It will just take time to learn this new technology.
So, don’t be overwhelmed by IPv6! It’s not like you have to learn an entire new networking model top to bottom. After all, the bottom line is that it is just layer 3 – IP. Begin reading books on the subject and more importantly start deploying it in a lab environment. Soon you’ll have valuable knowledge and experience with the IPv6 protocol which will make you a more complete engineer. To get started, here are a few resources I’d recommend as you begin your quest for IPv6 knowledge and experience:
Understanding IPv6 – This is an excellent book to read to start learning about IPv6. Joe Davies is an outstanding writer and the third edition of this book is due out this summer. Ed Horley, a preeminent expert in the field of IPv6 and co-chair of the California IPv6 Task Force is serving as the technical reviewer so it is sure to be outstanding.
IPv6 Essentials – Another great book about IPv6 written by Silvia Hagen.
IPv6 test lab guide – Test lab guides are essential for learning new features of the Microsoft operating system and applications. The IPv6 test lab guide provides detailed and prescriptive guidance for deploying IPv6 on a Microsoft network.
Posted by Richard M. Hicks on May 8, 2012