|
“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:
- ISATAP – stands for the Intrasite Automatic Tunnel Addressing Protocol. The UAG DA server will set itself up automatically as an ISATAP router and provide your IPv6 aware hosts IPv6 addresses and routing information. ISATAP capable hosts include Windows Vista and above and Windows Server 2008 and above. What do you need to make this work? Not much. Enable your DNS servers to answer queries for ISATAP, enter ISATAP Host (A) records on your DNS servers, and make sure IPv6 is enabled on your network hosts (it’s on by default, but some people turn it off). That’s it! Now all your IPv6 hosts on the network have IPv6 addresses, and you didn’t have to do anything other than run the UAG DA wizard, configure the DNS server a little bit and not turn off IPv6 to make it work. No IPv6 jockey license required. Oh, and one more thing, since ISATAP tunnels IPv6 packets within an IPv4 header, routing within your IPv4 infrastructure will work just fine, no changes on your IPv4 routers required. None, not any.
- 6to4 – is a IPv6 transition technology that the DA clients and UAG DA server can use to connect the DA client to the UAG DA server over the IPv4 Internet. 6to4 is used when the DA client is assigned a public IP address. The IPv6 packets are encapsulated in a IPv4 header and send over the 6to4 tunnel adapter to the DA server. What do you need to do to make this work? On the client, nothing – it works automatically after you run the UAG DA wizard and have Group Policy applied to the DA client. On the server – again nothing. Just run the UAG DA wizard and apply the Group Policy to the DA server and it works. Again, you can know nothing about IPv6 transition technologies and it just works. IETF membership not required.
- Teredo – is another IPv6 transition technology that enables the DA client to connect to the DA server over the IPv4 Internet. In this case, Teredo is used when the DA client is located behind a NAT device (either a NAT router or a NAT firewall) and the device allows outbound UDP port 3544. If the DA client has a private IP address and outbound access to UDP 3544, then the DA client uses Teredo to encapsulate the IPv6 messages from the DA client to the UAG DA server in an IPv4 header to send over the IPv4 Internet. What do you need to do to make this work? Like with 6to4, just run the UAG DA wizard, apply the Group Policies, and the DA client and UAG DA server are automatically configured to use Teredo. Holy Toledo!
- IP-HTTPS – is yet another IPv6 transition technology that allows the DA client to connect to the UAG DA server over the IPv4 Internet. IP-HTTPS is a “last ditch” method to encapsulate the IPv6 packets in an IPv4 header. When the client is assigned a private IP address, and the NAT device or firewall is configured to allow only HTTP/HTTPS outbound, then the DA client falls back to IP-HTTPS. The reason why we consider IP-HTTPS to be a “last ditch” effort is that yout users are going to find IP-HTTPS connections to not be quite as “performant” as 6to4 or Teredo connections (assuming that they’ve been paying attention). This makes sense when you think about adding SSL to the already existing IPsec computational efforts and the extra protocol overhead involved with using HTTP as the transport. What do you need to do to make this work? Ha! Nothing – the UAG DA wizard creates the configuration, creates the Group Policy settings and all you need to do is wait for the Group Policy settings to be applied to the DA clients and UAG DA server and away you go. No muss, no fuss.
- NAT64/DNS64 – NAT64/DNS64 (pronounced NAT 6 to 4/DNS 6 to 4) is a cool little piece of technology that the UAG team put together so that you can get DA working with the software assets you likely have running today. If I had to bet a quarter, I’d say that not everything on your network was IPv6 capable (that is to say, capable of running native IPv6 addressing or act as a ISATAP host). That would include all those Windows 2000 and Windows 2003 Servers you have on the network (yes, I know quite a few of you are still running Windows 2000). Since neither Windows 2000 nor Windows Server 2003 are IPv6 capable, you need a little help to get them to work with DirectAccess. No problem! NAT64/DNS64 accepts the connections from the DA client, automatically creates a IPv6 address for the name requested by the client, and then does a “NAT” kind of protocol transformation so that the IPv6 communication from the DA client is forwarded to the IPv4 only server on the network using IPv4. The response is returned to the DA server, which translates the IPv4 response into an IPv6 message that is returned to the DA client. Nice! But what do you need to know, what do you need to do to make this work? Enable two checkboxes in the UAG DA wizard. That’s it.
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.
HTH,
Tom
Tom Shinder
tomsh@microsoft.com
Microsoft ISDiX\Anywhere Access Team
UAG DirectAccess |