My name is Ben Bernstein and I’m a Program Manager for the UAG team.
As a follow up to Nitzan’s blog post DirectAccess support in UAG, I want to share with you some additional thoughts.
Broadband internet connections have been commoditized to a point where anyone can use a 3G broadband connection from a laptop for a reasonable price, and possibly use Wi-Max or similar technologies in the future. I believe this process will create a growing need for business laptops to become “always connected”. Given that, I also believe that DirectAccess will become a very handy technology.
For me, getting into the office early in the morning is a challenge; traffic congestion is a nightmare around here. However, I just learned a new trick from a colleague of mine. Whenever he gets stuck in traffic he pulls over and uses his 3G USB stick to work seamlessly as if he was actually in the office, and when traffic clears he gets back on the road. Luckily, our internal DirectAccess deployment enables him to work seamlessly, as if he is directly connected to our corporate network. He practically does everything from his laptop - mails, IM/VOIP, access to internal web sites and file shares, Terminal Services to his workstation, code check-ins - everything!
Most of you are probably raising an eye-brow right now and asking “What does DirectAccess add on top of our existing VPN solution?” I guess there are several answers, but for me the two important points that are inherent in the DirectAccess design are “Separation of user identity and machine identity”, and “Strong client side tunneling technologies”.
“Separation of user identity and machine identity” – DirectAccess technology is based on IPsec tunneling, where the traffic is split into two IPsec tunnels. One tunnel deals with machine based traffic, including services that make the machine “Always managed”/”Always up to date”. Another tunnel deals with user based traffic. This separation enables a given machine to be fully “IT accessible” whenever it is switched on and connected to the internet. It also enables a more sophisticated scenario in which the machine is fully “IT accessible” at all times, but only when users present a smartcard, do they get access to the corporate resources.
“Strong client side tunneling technologies” – DirectAccess technology uses IPv6 network connectivity, behind the scenes. IPv6 provides two great tunneling technologies which are being used in DirectAccess and are part of Windows Server: Teredo and IP-HTTPS. These two technologies enable DirectAccess clients to connect to the gateway even if they are behind a NAT device or behind a router that opens up only port 443.
There are many other aspects of the DirectAccess deployment I’d like to share with you - such as how are configuration settings provisioned to DirectAccess clients? (in short “group policy”). Do I need to make IPv6 related infrastructure/server side changes to support DirectAccess? (in short ,NO. UAG supplies NAT64 on box). How one can make DA highly available, scalable, etc... using UAG? (in short, UAG supports both Windows Network Load Balancing, and external Load Balancers). But … traffic has cleared I have to go J… so you will have to look out for my next blog post…
These are great observations, but when NAT64 is used, what are the IT management issues? Does IT have the same visibility into the DirectAccess clients so that they have the same management capabilities? Or is it the case that when NAT64 is used, access essentially a one-way situation, where users can get into the network, but I cannot manage the clients?
The "manage out" tunnel enables the machine to talk back and forth with internal resources even when a user isn't logged in, (and in smartcard enforcment scenario - even when a smartcard isn't in the reader). If you use NAT64 addresses, you would have access to the machines, however the machines won't be able to initiate connections back to your machine. Luckily many manage out protocols (such as GP, SCCM, anti-virus signitures and many others) poll the servers for updates and not the other way around. This is generally a good practice (even when IPv6 isn't present)since it enables NAT traversal, and enables each client to save its own state...
Hope this helps... Let me know if you have more questions...