Introduction
The way that people work is changing. You know that, because you have to help your company enable its employees to work in the new way. For a number of reasons, people need to be able to work more and more when away from the office. It could be that the company is trying to save money by reducing the amount of office space required, or it could be that employees need to work away from the office more in order to get closer to the customer, or because they need more flexibility to balance their work and personal schedules. For whatever reason, most companies have found that when they enable employees to work remotely, they gain a competitive advantage.
The problem for you, as an IT administrator, is determining what is the best way to enable remote access. The type of remote access you provide users can have a profound influence on the end user experience. In addition, different types of remote access have different security implications.
The most common methods of remote access provided to employees, contractors and partners include:
- Remote access VPN – This kind of remote access solution typically involves getting remote users global access to the intranet. While this minimizes application and access issues, it can create security issues. While some firewalls like the TMG firewall can allow very granular access controls over what users can do via a VPN connection, in most cases administrators do not lock down the VPN connections.
- SSL VPN Portals – SSL VPN portals give users access to applications that are made available to them through a portal interface. The UAG SSL VPN server can do this and is one of the best SSL VPN portals on the market today. However, the end-user experience is somewhat limited and SSL VPN portals are best used for users for which least privilege access is required. These would include partners and customers and contractors who need access to a small collection of applications, but for whom you do not want to provide an intranet experience.
- Application Gateways – Application gateways allow users to take advantage of rich client applications, such as the OCS client or Outlook, from remote locations. Users don’t need to connect to a portal or do anything in particular to make these applications work. All the users need to do is start the application and it works because you’ve configured things on the back-end to make sure that they work. However, not all applications can be enabled through application gateways and therefore the end-user experience is again limited.
While I’ve focused on the end-user experience for each of these remote access technologies, we also need to consider the administrator’s experience. One of the problems that IT groups have to deal with when enabling remote access to employees is that they have a hard time managing these computers. Sure, when the clients are connected to the VPN, IT might be able to manage the computers to a certain extent. But let’s face it, as a user, unless you have to start a VPN connection, you’ll probably not do so. Instead, you’ll get your email over RPC/HTTP in Outlook, and you’ll use web applications for the rest of the work you need to do. This leads to a situation where IT is not able to “touch” the computer and so the computer falls out of compliance and IT does not have control of the computing and application environment. This can lead to security and maintenance issues that can drive up costs.
What we really needed was a solution that allows employees to always be connected without having to jump through hoops, and for IT to always have control over the systems under their care – and now we have it. That’s where UAG DirectAccess comes in. When you use UAG DirectAccess, the DirectAccess client computer is always connected to the intranet so that IT is always able to control, manage and maintain that computer. And users are always able to connect to intranet resources to get their work done. They don’t need to connect to portals, they don’t need to hassle with VPN connections, and they don’t need to worry about whether there is an Internet gateway for their applications. They work the same way at home, in their hotel rooms, at conference centers, at partner sites, or at customer offices as they do when they’re in the corporate headquarters.
Does this sound too good to be true? In some respects, it might be. Why? Because DirectAccess has its networking foundation in IPv6. I know that when many of you hear about IPv6, you think about the location of the closest door. However, you probably really like the idea of an always on, always managed remote access solution. Is there a way we can get all the benefits of UAG DirectAccess without having to deal with a painful IPv6 learning curve? Yes, there is!
Enter UAG NAT64/DNS64
DirectAccess clients connect to the UAG DirectAccess server using IPv6 based IPsec tunnel mode connections. In fact, there are two of these connections made between the DirectAccess client and the UAG DirectAccess server: the first connection is called the infrastructure tunnel and that is used to allow the DirectAccess client to connect to management servers, DNS server, NAP servers, and authentication repositories (Active Directory domain controllers). This connection is made in the context of the computer account. The second connection, referred to as the intranet tunnel, is the one that allows the user to access resources on the intranet that the user is authorized to access. This connection is made in the context of the logged on user.
The DirectAccess client only “speaks” IPv6 over the DirectAccess connection. This works fine if the servers and other resources (such as printers) on the intranet are IPv6 capable (for example, they are using native IPv6 addresses or ISATAP IPv6 addresses). However, if you have a typical network, most of your network services and infrastructure are IPv4 only. This is a problem for the DirectAccess client, because it doesn’t know what to do with IPv4 addresses.
The solution is to use UAG DirectAccess. With UAG DirectAccess (in contrast to the DirectAccess that comes with Windows), you get the NAT64/DNS64 service, which allows the DirectAccess client to communicate via IPv6 to the UAG DirectAccess server, but then enables the UAG DirectAccess server to forward the connections as IPv4 connections to the servers and other devices on the intranet. When the responses are received, the UAG NAT64/DNS64 service then converts the IPv4 responses to IPv6 messages and forwards those to the DirectAccess client on the Internet.
Wow! Sounds Great – But what’s the Catch?
So you really don’t believe that you can get something for nothing. Well, you’re right; there is a catch. Since DirectAccess is really designed to support IPv6 capable networks, the NAT64/DNS64 is designed to “get you over the hump” until you move your network over to an IPv6 capable network. For some of us, that might take a year or two, for many of us, it might be sometime in the 2020s. In either case, most of us are going to be using IPv4 only resources for some time.
So there are some limitations imposed by NAT64/DNS64. These include:
- IPv4 only management servers and workstations will not be able to initiate connections to the DirectAccess clients. The reason for this is that the DirectAccess clients register an IPv6 address in DNS. The IPv4 systems that try to connect to the DirectAccess client won’t know what to do with the IPv4 address they receive.
- Some applications require “call backs” using what we often refer to as “complex protocols”. If the application protocol requires the server to initiate a new, unsolicited inbound request to the DirectAccess client, the connection will fail if the resource initiating the connection is an IPv4 only resource.
- Some applications embed IPv4 addresses in their application configurations or application protocols. Since the DirectAccess client doesn’t know what to do with IPv4 address (when using the DirectAccess tunnels), it won’t be able to use that application.
Now some people might think “well, that’s not good, because I won’t have the management control that I need”. But when you think about it, in most cases management is done through agents installed on the clients. The agents call the management servers and receive the information they need. In very few scenarios does the management server “push” information to the clients. In this scenario where the agents are calling management servers on the intranet, the NAT64/DNS64 solution will work just fine. The only management scenario that will fail is when the management server needs to initiate a connection to push information or applications to the DirectAccess clients.
OK, Cool – I Can Deal with That – What Else Do I Need?
If yours is a small or mid-sized business, then you can do UAG DirectAccess “the easy way”. Here’s what you need:
- A UAG DirectAccess server. This requires Windows Server 2008 R2 and Unified Access Gateway 2010 (UAG).
- A DNS server. It doesn’t have to be a Windows DNS server, and it doesn’t even need to support IPv6 if you’re going to use only IPv4 using UAG NAT64/DNS64.
- A Windows Active Directory domain. There are no domain functional level requirements, and you don’t need a Windows Server 2008+ domain controller. Windows Server 2003 domain controllers will work fine.
- An internal PKI. You need to be able to assign computer certificates to the UAG DirectAccess server and the DirectAccess clients. You also need to assign a web site certificate to a “network location server” that’s used by the DirectAccess clients to tell them whether they’re on the intranet or not.
- An internal web server that can host an SSL site. You can use an existing SSL site if you have one, or if you don’t, you can set up a simple SSL site. It doesn’t have to run on IIS, but if you have an IIS site or want to put one up, that will work fine.
- An optional public certificate for the UAG DirectAccess server, so that you can assign it to the IP-HTTPS listener. IP-HTTPS is one of the IPv6 transition technologies that DirectAccess clients can use to connect to the UAG DirectAccess server over the IPv4 Internet. Alternatively, you can use a private certificate for this, but then you need to publish the CRL, which might be more of a hassle than it’s worth.
That’s about it! Those are the core requirements and they’re really not that complicated. I set it up in my office and it works great! Never do I have to wonder whether my VPN connection is going to work, and I don’t have to limit myself to web applications. I can get to anything on my intranet no matter where I am. And it’s all secured with IPsec encryption, computer account authentication, and Kerberos user account authentication.
Summary
In this article, we went over some of the remote access technologies that are used to allow users to access resources on the corporate intranet. Then we discussed DirectAccess and how DirectAccess provides a superior solution for managed clients. However, since DirectAccess clients only speak IPv6, a solution is needed for those of us who are still running IPv4 networks. We saw that the UAG NAT64/DNS64 service solves this problem. With NAT64/DNS64, we don’t have to worry about IPv6 on the intranet and can access all our resources when working remotely as we do when we’re on the intranet. In the next article, I’ll show you the component services and how they work to make DirectAccess easy. See you then! –Deb.
