We all know that there’s a problem with traditional VPNs. It doesn’t matter if they’re PPTP, L2TP/IPsec, SSTP or even IPsec tunnel mode. They all have the same problem: the user has to do something to get them started and they don’t always work from all locations (with the exception of SSTP, which works from behind any firewall or Web proxy that allows outbound HTTPS).
This creates a real problem for organizations that want to allow free and easy access to resources on the corporate network for users who have managed machines (we’ll confine our discussion for users of managed machines here, since unmanaged machines should use a gateway device to connect to resources hosted on the corpnet). For employees with managed machines, you want them to have the same experience they have while on the corpnet, regardless of their location. In essence, you want to extend the domain to any managed computer, located anywhere in the world.
Does this sound like a pipe dream? Maybe, but the fact is that with Windows 7 and Windows Server 2008 R2, you have a new VPN solution called DirectAccess. With DirectAccess, you can extend your domain, your corpnet experience, to any managed machine, anywhere in the world. The user doesn’t need to start the VPN; the DirectAccess VPN starts with the machine, so you can manage that machine and apply Group Policy and obtain management information for System Center just like any other machine located on the corpnet. When the user logs in, a second DirectAccess VPN connection is automatically established, all transparent to the user. The user never needs to initiate a connection to the DirectAccess Server.
However, for the ISA or TMG firewall operator, you’re going to find yourself in a bit of a pinch. The problem here is NAT traversal. When the DirectAccess client connects to the DirectAccess server, it uses an IPsec connection to do this. What’s interesting is that Microsoft has included a number of protocols that the DirectAccess client can use to tunnel the IPv6 connection to the DirectAccess server over a IPv4 Internet. These technologies allow the DirectAccess client to connect to the DirectAccess sever even when the client is behind a NAT device – similar to the NAT Traversal you might be used to using with your L2TP/IPsec ISA or TMG VPN servers.
At this point you might think that it’s all good. However, there’s one little glitch. The problem isn’t that the client can’t be behind a NAT device, because the client can. However, the DirectAccess server cannot be behind a NAT device, which is unlike the situation with the L2TP/IPsec VPN server.
This has the potential for creating a real problem for you, since you obviously want the DirectAccess server behind the ISA or TMG firewall, not in parallel. The DirectAccess server isn’t a firewall and wasn’t designed to be one, so you have a right to be a little nervous about putting it on the edge of your network.
So the question is: is it possible to put the DirectAccess server on the ISA or TMG firewall? First, we can say that this scenario is never going to work with ISA, since ISA is a 32-bit application and will never work on Windows Server 2008 R2, which will only be available as a 64-bit operating system. How about TMG? TMG will run on Windows Server 2008 R2, and a DirectAccess Server requires Windows Server 2008 R2. If you check the System Policy Rules on a TMG firewall (which is currently in Beta 3), you will find references to DirectAccess. These rules include:
You can also see in the System Policy Editor a configuration group for Direct Access Rules:
So will this work? And if so, do we need to manually enable these System Policy Rules, or maybe these rules will be enabled when we configure the TMG firewall with the DirectAccess Server Role? These and many more questions need to be answered, and the good news is that in two weeks I’ll have a vacation and will be able to take some time to figure this, as well as other TMG firewall mysteries, out!
See you then!
Thomas W Shinder, M.D., MCSE
Sr. Consultant / Technical Writer