(Discuss UAG DirectAccess issues on the TechNet Forums over at http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag)
“All our times have come Here, but now they’re gone Seasons don’t fear the reaper Nor do the wind, the sun or the rain (We can be like they are) Come on baby (Don’t fear the reaper) Baby, take my hand (Don’t fear the reaper) We’ll be able to fly (Don’t fear the reaper) Baby, I’m your man….”
Listen to 30 seconds of the song here (play #3)
OK, enough of the Blue Oyster Cult, let’s get down to business.
Whenever I introduce people to DirectAccess, I start with all the great things it has to offer. IT gets to control and manage the DA clients on the Internet in the same way they control and manage clients that never leave the corpnet. End users get to connect to what they need on the corpnet without having to think about it. Everyone is happier than ever and this is what IT and end users have been waiting for, what everyone really was expecting of remote access since the first dial-up connection was made way back in the 20th century.
After the troops get charged up about what DirectAccess has to offer, I get to the foundations of the solution. I start with Windows Firewall with Advanced Security. OK, that’s cool, we’ve all worked with host-based firewalls and that’s no problem. Then I get to IPsec. Hmmm. That’s a little scary, but then, most of us have used IPsec for L2TP/IPsec connections, and some of us have even used it to connect VPN gateways using site to site IPsec tunnel mode connections. So while a little scary, IPsec isn’t a deal breaker. DNS? No problem! How about creating SSL web sites? Again, total no brainer. Certificates and PKI? Sometimes problematic, but putting together a PKI and issuing certificates is pretty mainstream these days, and DirectAccess doesn’t impose any “off-label” type of certificate requirements, just everyday computer and web site certificates. So even when PKI is on the table, DirectAccess is still looking like a might juicy proposition.
Then I say “IPv6”
Jaws drop, eyes glaze over, smiles turn to frowns, elation turns to desolation, and the entire upbeat nature of the conversation turns into a something akin to a funeral procession.
When that happens, I’ve got to turn things around fast, or else it it’ll turn from “Don’t fear the reaper or IPv6” to “you’ve lost that lovin’ feelin”. The good news is that when you deploy DirectAccess using UAG, you don’t need to fear IPv6 (and maybe the reaper too).
I understand the trepidation involved with IPv6. A lot of companies have already decided that there is little to gain from IPv6, and that it’s unlikely that we’ll see widespread adoption of IPv6 on the Internet in our lifetimes. So why deal with what looks like a complicated mess of 128 bit numbers that are impossible to remember and a new addressing scheme that makes IPv4 look like child’s play?
True, DirectAccess uses IPv6 communications as it’s foundation. All communications from the DA client to the UAG DA server are IPv6. This means that the client application on the DA client must be IPv6 aware. However, the server doesn’t need to be IPv6 aware, because UAG has a few tricks up its sleeve to make it all work.
In fact, the UAG DA server has enough technology built right in so that you can completely avoid any understanding of IPv6 and still get DirectAccess working on your network. Now, I’m the last guy in the world who would advocate that you should know nothing about the basic underlying networking technologies that run your solution. And I bet that once you get into the DirectAccess game, you’ll want to dig into IPv6 a little more. What you’re really concerned about is having to become an “IPv6 networking jockey” and end up in a 4 year long course of study on IPv6 before even getting started on DirectAccess.
As we say here in Texas “that dog don’t hunt”
And we don’t need that dog to hunt. Here are some of the technologies used by UAG DirectAccess that allow you to put some skin in the DirectAccess game without putting on an IPv6 propeller cap:
There you go. IPv6 for the UAG DA admin. The point is that you need to know very little if anything about IPv6 to get a production ready UAG DA server up and running. Will you benefit from getting to know some about IPv6? Sure, as you’ll understand what’s going on in the background and you can be more flexible in your deployment. Will you benefit from being an IPv6 jock? You bet! When you reach that level of sophistication you can start thinking about moving your corpnet into native IPv6, and use IPv6 aware routers, switches, NIDS and the rest. Knowledge is always power, but UAG DA already includes quite a bit of power on its own so it spares you from the rigors of intimate (or even passing) knowledge of IPv6.
So don’t fear IPv6. The seasons don’t fear IPv6, nor does the sun nor the wind nor the rain. You can be like they are! However, since 98%+ of you reading this are probably men, I’m not going to call you “baby” and I’m not “your man” :)
I’ll talk more about IPv6 concepts in the future on this blog and also in some guides I’m planning on putting out that will provide you with some “kissing cousin” familiarity with key UAG DA IPv6 concepts. Not enough to blow your mind, but enough where all the pieces will fall into place quickly so that you’ll maybe get jazzed enough to look into IPv6 a bit more when you have the time.
Microsoft ISDiX\Anywhere Access Team
We are piloting DA with UAG internally before demoing it to clients, am I right that with DA standard you get a few extra features:
you can initiate connects to clients from the internal network where as with UAG DA you cant, the connection to inside has to be initiated from the client (not a problem for most things like SCCM management)
Also with DA you can control which servers you can communicate with but with UAG DA you get "all or nothing" (unless you use nap, then its if your healthy you get everything)? or is that where the "end to end" IPSEC comes in?
You bring up two issues here that are worth discussing:
First, there is the issue of "manage out" or the ability of an internal client to initiate a connection to a DA client from the corporate network
Second, there is the issue of being able to use IPsec for end to end security
UAG DA fully supports the "manage out" scenario. You have to create a firewall rule that enables edge traversal for the protocol you want to use, but it works fine (and the same) on Windows DA and UAG DA. So if you want full "manage out" capabilities, you can use the UAG DA in the same way as the Windows DA. In both cases you need to create the firewall rules.
Second, the issue with end to end IPsec security. You can use UAG DA to create end to edge connections for all DA clients and you can create policies that enable end to end IPsec security using UAG DA. This feature is available in both Windows DA and UAG DA.
So, if you want to use UAG DA and benefit from NAT64/DNS64, array configuration and management, NLB, and other UAG features, you can check out UAG for your DA solution. Thanks! --Tom