Book Image

Windows Server 2012 Unified Remote Access Planning and Deployment

Book Image

Windows Server 2012 Unified Remote Access Planning and Deployment

Overview of this book

DirectAccess, introduced in Windows Server 2008 R2, has been a ground breaking VPN-like connectivity solution, adopted by thousands of organizations worldwide. Allowing organizations to deploy without manually configuring every client and providing always-on connectivity has made this technology world-famous. Now, with Windows Server 2012, this has been made even easier to deploy, with a new friendly user interface, easy-start wizard and built in support tools.With Unified Remote Access, Windows server 2012 offers a unique way to provide remote access that is seamless and easier to deploy than traditional VPN solutions. With URA, the successor to DirectAccess, your users can have full network connectivity that is always-on. If you have deployed Windows Server 2012 or are planning to, this book will help you implement Unified Remote Access from concept to completion in no time!Unified Remote Access, the successor to DirectAccess, offers a new approach to remote access, as well as several deployment scenarios to best suit your organization and needs. This book will take you through the design, planning, implementation and support for URA, from start to finish."Windows Server 2012 Unified Remote Access Planning and Deployment" starts by exploring the mechanisms and infrastructure that are the backbone of URA, and then explores the various available scenarios and options. As you go through them, you will easily understand the ideal deployment for your own organization, and be ready to deploy quickly and easily. Whether you are looking into the simplest deployment, or a complex, multi-site or cloud scenario, "Windows Server 2012 Unified Remote Access Planning and Deployment" will provide all the answers and tools you will need to complete a successful deployment.
Table of Contents (17 chapters)
Windows Server 2012 Unified Remote Access Planning and Deployment
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Index

Protocol transition technologies


Ultimately, not many organizations are ready for IPv6, and even those that are can't always go ahead full steam, as the costs can be significant. Many models of network hardware such as switches and routers can be upgraded to support it, but quite a few still don't, not to mention various embedded OS devices like vending machines, cash registers, entry control systems, and others. To make things easier, several transition technologies have been developed. We've already mentioned a couple of them, and now is the time to go into more detail and understand a bit about all of them and how they affect your network and deployment plans.

ISATAP

As we said before, ISATAP is a mechanism designed to allow IPv6 capable hosts to communicate over an IPv4 network. This would be useful if your network infrastructure (not referring to the cables, but to routers and the like) is older hardware.

ISATAP has some conceptual similarities to the connection mechanisms used by URA clients, but it is only used on the internal network and has a different purpose. It is designed to allow your URA clients to access IPv6-capable hosts (such as application servers or other computers on the internal network) even though your infrastructure is an IPv4 network. With ISATAP, the IPv6 data is encapsulated inside an IPv4 packet header, so the network infrastructure just passes it along, not knowing what's really inside. Hosts that are able to use ISATAP have a dual stack, meaning that they are configured with both an IPv4 IP address and an IPv6 IP address that is based on the IPv4 address. That IP starts with a standard prefix followed by five address groupings and then the IPv4 address.

To facilitate ISATAP, your network needs an ISATAP Router. This is not a physical router, but a software component that the URA server provides (you can also configure other servers to host this functionality). When you configure the URA role, you have the option of setting up the server as an ISATAP router. You can also configure any Windows server to be one, so you can have your URA server perform this function or configure it on another server.

When ISATAP capable hosts boot up, they will also need to know whether to use ISATAP or not, and for that, they will query the DNS server. In an environment that uses ISATAP, the DNS server would have an entry that will resolve the hostname ISATAP to the IP of the ISATAP router. Clients that are successfully able to resolve this will contact the IP provided, and will get their ISATAP configuration from the ISATAP router.

As an administrator, you have the option of either using ISATAP or not. Like any technology, ISATAP has advantages and disadvantages, and Microsoft does not recommend deploying it, except as a temporary means of enabling IPv6, while the organization prepares for full IPv6 implementation. In Chapter 8, Enhanced Configurations for Infrastructure Servers, we will discuss the advantages and some of the challenges of ISATAP, as well as how to enable this feature or move it to another server. If you want to enable ISATAP right now, follow these steps:

  1. Open your domain's DNS server management tool.

  2. Create an A record named isatap under the forward lookup zone of your domain name.

  3. Populate it with the IP of the URA server (if the URA has both an external and internal NIC, use the IP of the internal NIC).

  4. Open Registry Editor on the DNS server.

  5. Navigate your way to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Parameters.

  6. Double-click on the GlobalQueryBlockList value.

  7. Remove the name isatap from the list (it's perfectly normal for it to contain nothing else, but it would probably have wpad as well, which you should leave alone).

  8. Click on OK and exit Registry Editor.

  9. Restart the DNS service or reboot the DNS server.

  10. Repeat steps 4 to 9 on all your DNS Servers.

Well, we have ISATAP to take care of IPv6-capable hosts, but what if we want to access hosts that can't use ISATAP? Older operating systems, such as Windows 2000 and older are not able to use ISATAP—the component is not included in the operating system. This also pertains to many non-Microsoft platforms that you might be running. For them, URA includes two additional services—DNS64 and NAT64, which are discussed in our next topic.

DNS64 and NAT64

URA clients communicate using IPv6, and so for things to work correctly, any resource they need to communicate to must resolve to an IPv6 IP address. The DNS64 service helps take care of that. DNS64 (pronounced DNS six-to-four), as its name suggests, is in charge of resolving the IP addresses for the URA clients. When a URA client needs to communicate with an internal hostname, the DNS64 component provides an IPv6 address that represents the IPv4-only host.

NAT64 (pronounced NAT six-to-four) performs an action that somewhat resembles what traditional NAT does, but specifically for IPv6 transition. The acronym is the same—Network Address Translation—but where traditional NAT "translates" traffic from public IPs to private IPs and vice-versa, NAT64 translates traffic from IPv6 hosts to IPv4 hosts and vice versa.

Note

It's important to keep in mind that these two are almost completely transparent to both you and your users. The URA wizard will turn those on, and that's it.

6to4

As opposed to the mechanisms we described earlier, 6to4 is more of a client-side mechanism. It's designed to allow IPv6-capable hosts, such as your URA clients, to communicate with your URA server over the Internet, significant parts of which are still only IPv4 capable.

6to4 is a component of the operating system, which takes the form of a virtual network adapter. You can even see it in the computer's device manager:

For 6to4 to work, the operating system assigns itself an IPv6 address which is based on its IPv4 address. Then, when the computer needs to communicate with another IPv6 host, such as your URA server, the 6to4 component embeds the IPv6 packets in the payload portion of an IPv4 packet with protocol type 41. These IPv4 packets are then sent to the IPv4 address of the URA server, which extracts the IPv6 packet back, and passes it along to the IPv6 stack.

One challenge with 6to4 is the fact that protocol 41 is blocked by default on many networks. If either the client's ISP or the ISP that your corporate network uses blocks this protocol, 6to4 communications won't work. Another potential pain in the neck is that 6to4 cannot work behind a NAT network, because a 6to4 address is generated only when the client has a public IPv4 address (as opposed to ones that are behind a router and have a NAT address). Since home routers, which perform NAT translation, are very common these days, this effectively blocks the 6to4 mechanism. Thankfully, there are additional mechanisms like IP-HTTPS and Teredo, which we'll discuss in the next sections.

The bottom line of this, as far as you are concerned, is that you have little control over this option. When you configure your clients to use URA, some of them will establish their connection using 6to4, but only those that have a public IPv4 address. This means, of course, that only a small portion of your clients will do so. Those which cannot use it will automatically fall back to one of the other mechanisms, which we will discuss next.

Teredo

For URA clients connecting from the Internet, Teredo is another client-side transition technology, which is the fallback when 6to4 cannot be used. When a URA host is unable to use 6to4, usually because the protocol 41 is blocked, Teredo springs into action. With URA, Teredo is yet another virtual network card (as opposed to the pesky Teredo Navalis clam!), and this is how it looks:

You can also see it in the preceding screenshot, at the bottom of the screen. The Teredo adapter is included with modern Windows computers.

Teredo also encapsulates the IPv6 packets within IPv4, but it uses UDP packets on port 3544 instead of protocol 41. With UDP being more ubiquitous than protocol 41, it's less likely to be blocked by the network infrastructure, and therefore more likely to go through in most networking environments. In addition, Teredo has a special mechanism that allows it to transcend through NAT networking, so it can work even if the client is behind a home router.

On a Teredo client, such as your URA clients, the operating system assigns itself a unique IPv6 address, which is also based on its IPv4 address. The address begins with the prefix 2001:0000, followed by the IP of the Teredo server (4137:9e76 in the preceding screenshot). The address also has the UDP port mapped on the NAT device (b4 in the preceding screenshot) and finally, the public IPv4 address of the host (e7ee:3d10 in the preceding screenshot). This IP is not the IP of the host itself, but the public address that the NAT device uses.

Some of these numbers are obfuscated with a binary inversion of the bits. For example, the externally mapped UDP port is b4 as shown in the preceding screenshot, but that's actually FF4B (65355). To calculate the number, if you care to go that deep, launch your Calculator and switch it to the Programmer mode. Then, perform b4 xor ffff and you will arrive at this result:

The IP of the host is obfuscated similarly.

Note

Do you know what IP it actually represents? (Answer at the end of the chapter!)

Once Teredo comes into play, the server performs a discovery process to determine the type of NAT that the client is behind, which helps it determine how to communicate with it reliably. Once this process concludes, the IPv6 traffic is encapsulated and the communication process can continue.

The practical considerations for using Teredo are few, as you have little to do. Just like 6to4 that we mentioned earlier, the user or you have little control over which mechanism is used—it depends on the network infrastructure. If the network blocks protocol 41, 6to4 cannot be used, and the client will automatically fallback to Teredo, and there's nothing you can really do about that (other than, of course, to tell the user to connect to the internet somewhere else, where protocol 41 is not blocked).

Note

There are actually several types of NAT connections. These are:

  • One-to-one NAT, also known as Full-cone NAT

  • Address-restricted cone NAT

  • Port-restricted cone NAT

  • Symmetric NAT

Occasionally, Teredo may run into a situation where even it is unusable. This could happen in certain networks where the type of NAT cannot support Teredo, or when UDP port 3544 is blocked by the network infrastructure or ISP. It's pretty rare, but not unheard-of, and in such situations, an affected client will automatically fall back to yet another mechanism, which we will discuss shortly. One thing you can do is manually disable the Teredo interface, and that's something you might need to do as part of troubleshooting. We will discuss troubleshooting URA in Chapter 10, Monitoring and Troubleshooting Unified Remote Access of the book.

IP-HTTPS

IP-HTTPS is the third IPv6 transition mechanism used by URA clients and is the last fallback mechanism in case both 6to4 and Teredo fail to connect. With IP-HTTPS, IPv6 packets are encapsulated inside the HTTPS traffic, which is sent over the TCP/IP port 443. From the three client-side transition mechanisms, IP-HTTPS is the most reliable, because almost no network blocks HTTPS traffic, and so it's virtually impossible for this mechanism not to work (beyond specific misconfiguration or other technical malfunction, of course).

With the previous incarnation of Unified Remote Access (that is, DirectAccess), IP-HTTPS was considered to be a less desirable option, because the addition of the SSL encryption that HTTPS uses was somewhat of an over-kill, as the connection already uses IPsec. Double Encryption is not only redundant, but also costly, as it forces the client and server to work harder to encrypt or decrypt each packet twice. However, with URA, the SSL traffic actually does not encrypt the data (we refer to this as null-encryption), so there's less work for the client and server to do, and this results in better performance. In other words, if you have implemented DirectAccess in the past, and are used to thinking badly of IP-HTTPS, forget about it, as it's no longer an issue. In the following screenshot, you can see the IP-HTTPS virtual NIC in a Windows 7 computer's device manager:

On a client, IP-HTTPS is automatic, and there's nothing for you to configure. On the URA server, you will be required to get a digital certificate, which will be used by the server to prove its own identity to clients. This requires some planning and may be a bit of an effort to get. Also, it can prove costly, if you get it from the more expensive certificate providers. We will discuss this process later, when we will see how to configure the server.