Deep dive into UAG DirectAccess (IPv6 and DirectAccess)

Technorati Tags: uag - Unified Access Gateway,DirectAccess,IPv6,DirectAccess and IPv6,IPv6 prefixes,NAT64,DNS64

Ok, this time it’s going to be a long dive, hold your breath :)

I’ll skip my usual grandiose introduction, since there are many things I want to share today…

NAT64 and DNS64 on video

Oh, a quick note before I start, I had a discussion about UAG and DirectAccess with Stephen Bowie, which was recorded on TechNet Edge. If you’re looking for a little more information about the NAT64, DNS64 and other value added by UAG, you should check out this link (sorry about my haircut, I wasn’t aware this will be public :))

DirectAccess and IPv6

DirectAccess uses IPv6 for remote access. The reason behind it is that DirectAccess tries to look two steps ahead when thinking about remote access. Given the fact that public IPv4 addresses are running out, let’s consider the following scenario (outlined in the figure below). We have a client that is in one private network (in our case it contains S2 and Client), and it needs to have seamless remote access to another private network (in our case, the other network contains S1). Because both networks are using the same private IPv4 address space, IPv4 traffic is not routable between them, so we have an irresolvable conflict (In a classic IPv4 VPN scenario, the client can manually chose to connect to a VPN to access S1, but that is not seamless access).

In DirectAccess since the client is IPv6 based, it can access both S1 and S2. That is possible because from an IPv6 point of view all machines have unique IPv6 addresses. When the private network containing S1 is behind a UAG DirectAccess server (which is acts as a NAT64) the client would access S1 using S1's globally unique IPv6 address (intercepted by the NAT64). Local resources such as S2 would be accessible using IPv4 (or IPv6 if the network is IPv6 compatible). Here as you can see the client seamlessly accesses the network containing S1.

I’m not saying that the world will move instantaneously to IPv6, but when you plan remote connectivity for your organization you might start thinking about integrating IPv6 enabling technologies such as DirectAccess.

This is why today I want to focus on the how DirectAccess relates to IPv6 addresses in your organizational network.

A quick introduction to IPv6 addresses

I guess IPv6 is a very long subject which can’t be fully addressed in a blog post. I do however want to give a quick introduction to IPv6 addresses and prefixes. IPv6 addresses and prefixes were the hardest part for me when I moved to the DirectAccess realm. I just had to start looking at IPv6 addresses. I was quite shocked by the fact that they were 128 bits long, and I still have trouble comprehending this.

A useful thing I learned was that for many practical reasons for unicast addresses, you can look at the first 64 bits of an address and learn a lot. The rest of the bits, are well, less important… To be more specific, a given subnet is represented by the first 64 bits, the next 64 bits represent a computer in that given subnet.

When I look at the first 64 bits of a unicast IPv6 address inside an organization network I can usually categorize it into one of the following:

(The list below refers to prefixes. Prefixes are a list of hexadecimal digits, separated by colons, and followed by a forward slash, and the number of high-order bits in the prefix, pretty much like IPv4 subnet definition, e.g. 192.168.17.0/24 means the first 24 bits set to 192.168.17 (converted to binary) and 2002:836B:1::/48 means the first 48 bits equal 2002:836B:0001 (converted to binary).)

1. 2002:WWXX:YYZZ::/48

• This is called 6to4 address space
  • It means you own a public IPv4 address, and you're using it to generate a 6to4 prefix.
    • WWXX:YYZZ is the colon hexadecimal representation of w.x.y.z, which is the public IPv4 address you must own.
• It also implies you have (somewhere) a Window-based server that owns that w.x.y.z, which has assigned itself the following IPv6 address 2002:WWXX:YYZZ::WWXX:YYZZ
  • That server is called a 6to4 router.
  • It has a 6to4 router mechanism that enables it to route IPv6 traffic over the IPv4 internet using its IPv4 address (w.x.y.z).
  • Advanced note: If that server has other means of connecting to the IPv6 Internet, it is called a 6to4 relay.
• The UAG DirectAccess Server acts as a 6to4 router and relay, and in some cases uses the 6to4 48-bit address space for addressing (I will explain shortly)

2. FD00::/8 (called unique local addresses, works according to the following RFC)

• This means that the owner generated a random 48-bit IPv6 address space (he picked a random 40 bit number and appended it to FD00::/8)
  • Although these addresses are legal, they are not globally routable, and do not provide connectivity with the IPv6 Internet.
  • You can configure UAG DirectAccess to work with these types of addresses, but using these addresses is only recommended in a lab environment, rather than for long term deployment.

3. FE80::/64

• This is a link-local address, which is used between machines on the same subnet.
• If these are the only IPv6 addresses you have on a machine – the chances are that the machine isn't talking IPv6 with anyone :), at least not outside its subnet.

4. 2001:0::/32

• A client with such a prefix received its address from a Teredo server, which probably means it doesn't support native IPv6 connectivity.
  • E.g. My home machine (ISPs here don’t support IPv6 yet), Hotels, etc…
• Organizations usually don’t use these addresses internally, since by default Windows-based Teredo clients do not use Teredo on a managed intranet…
• UAG DirectAccess uses this address space for DirectAccess roaming clients. It acts as a Teredo server for them.

5. Other public IPv6 prefix (usually 48-bit, which usually represents a single organization)

• The prefix should have been assigned by IANA or a local Internet service provider.

A quick “advanced” note – 6to4 and Teredo clients use 6to4 addressing and Teredo addressing. IP-HTTPS clients, ISATAP hosts, and servers behind a NAT64 don’t use a specific address schema, so when these technologies are configured, a specific prefix should be configured for them. Such a prefix is usually allocated from one of the existing schemas: 6to4, unique local, or public (options 1, 2, and 5 above).

So, when you configure UAG DirectAccess you need to configure a prefix for the NAT64, ISATAP hosts (if ISATAP is configured), and for the IP-HTTPS clients.

How UAG configures DirectAccess IPv6 prefixes

When running the UAG DirectAccess configuration you pick the Internet facing and internal facing IP addresses.

When the Connectivity screen is displayed, behind the scenes UAG DirectAccess actually checks to see if you have IPv6 address on the internal facing UAG interface. If you do, it disables the Internal IPv4 address list box, if you don't it disables the Internal IPv6 address list box, however a lot more happens behind the scenes.

No IPv6 address on your internal facing UAG interface.

If you have an IPv4 address on the internal facing interface, DirectAccess assumes that you don’t have IPv6 deployed in your organization. It then uses the internal IPv4 address to configure the UAG DirectAccess server as an ISATAP router. If you use this option please note that Windows-based ISATAP hosts in your network can't use ISATAP until you register a DNS record of ISATAP (e.g. ISATAP.internal.contoso.com) in the DNS server (mind the Global Query Block List). Once you register the ISATAP name, Windows-based ISATAP hosts in your organization start using IPv6 and use the UAG DirectAccess server as their ISATAP router.

Behind the scenes UAG DirectAccess automatically configures the following prefixes using 6to4 notation:

1. 1. 2002:WWXX:YYZZ:8000::/49 as the organizational prefix
   2. 2002:WWXX:YYZZ:8000::/64 as the ISATAP prefix
   3. 2002:WWXX:YYZZ:8001::/96 as the NAT64/DNS64 prefix
   4. 2002:WWXX:YYZZ:8100::/56 as the IP-HTTPS prefix

An “advanced” note – the reason that /49 address space is used, is that the 6to4 address 2002:WWXX:YYZZ::WWXX:YYZZ is used for IPSec tunneling and cannot be part of the organizational prefix.

If there is an IPv6 address on your internal UAG interface.

This might be useful in cases where you:

• • Need a more advanced IPv6 deployment in your organization.
  • Want more control over the address allocation for remote access.
  • Are deploying a lab with a single subnet, where you use static IPv6 addresses.

If you had an IPv6 address on the internal facing interface, on the prefix configuration screen you need to enter three different IPv6 prefixes.

• Organization prefix
  • Here you allocate an IPv6 prefix using one of the options mentioned above (public, 6to4, or unique local) and go with it.
    • Since UAG DirectAccess uses the 6to4 server addresses to terminate IPsec tunnels, the 2002:WWXX:YYZZ::/48 prefix can’t be used as your organization prefix as it contains the UAG’s 6to4 addresses. You should use a 2002:WWXX:YYZZ:8000::/49 prefix in such a case.
      • In UAG RC0 you cannot specify a /49 prefix, please see a note below for a work around.
• IP-HTTPS prefix
  • Here you specify a prefix with a length between 56 to 64 bits.
    • If you plan to deploy a single server you can use /64. If you plan to deploy an array, you should allocate a wider range. See the UAG documentation for more information.
• NAT64/DNS64 prefix
  • You allocate a specific 96-bit prefix for your legacy IPv4 servers. The DNS64 adds an appropriate 32 bits, creating a 128-bit IPv6 address using the IPv4 address of the server.

Note ISATAP is not needed if an IPv6 address is present on the internal facing interface, hence no ISATAP prefix is required.

A work around for using 6to4 prefix in RC0

In UAG RC0 you are required to specify a 48-bit prefix for your organization. If you decide to go with 6to4 addressing, you should configure a third public IPv4 address on the Internet interface of the UAG machine (let's say w.x.y.t). After you do that a third 6to4 address is generated on the 6to4 interface of the UAG DirectAccess server. The new IPv6 address (2002:WWXX:YYTT::WWXX:YYTT) isn’t used for IPSec tunnel termination, and you should now use the new 2002:WWXX:YYTT::/48 prefix as the corporate 48 bit prefix.

An “advanced” comment: The reason the third public IPv4 address needs to be on the UAG Internet-facing interface, is so that DirectAccess 6to4 clients that want to access the organization 6to4 prefix, will try to connect to the IPv4 address derived from the 6to4 prefix (in our case w.x.y.t), and we need the UAG to listen for 6to4 traffic on that IP address.

Wrapping Up

So we had a little introduction to IPv6, how and why DirectAccess leverages that, and some drill down into how and why IPv6 prefixes are configured when you configure DirectAccess

OK, you can breathe again :).

Leave a comment below if you think there are more topics you want me to relate to.

Ben

Comments

• Anonymous
  October 14, 2009
  How would you configure multiple UAG Direct Access server in same domain? If we want different UAG and policies for different offices? Let's say we want one UAG for USA and one UAG for Europe. Now when you install the first UAG Direct Access server this server configure itself as an isatap-router etc. How would you configure the next UAG Direct Access server? How would you define isatap and ipv6 prefix etc. for this kind of configuration? I haven't found any information about this kind of configuration.

• Anonymous
  October 14, 2009
  Thanks for the feedback, I'll try to make sure it is incorporated in one of the publications we do for DirectAccess. In the meantime the short answer is that it is a little more complicated for several reasons, to relate to the ISATAP part, you probably want to create an external ISATAP router, and create a "Native" IPv6 connectivity between the ISATAP and the directaccess machines you can been an IPv6 address like I mentioned here and assign addresses to the machines, so when you'll run both UAGDA setups they will use the native IP addresses. On top of that you'll probably need to make sure the GPOs don't runover one another... You'll probably need a few shots to get this configuration right, and you might want to think of other workaround to achieve this... Thanks Ben

• Anonymous
  October 20, 2009
  The comment has been removed

• Anonymous
  October 22, 2009
  Let me try and refine the message from the solution accelrator guide: There are actually two types of issues:

1. Some client-server applications don't support IPv6 well. Although NAT64 solves the problem on the server side, some applications don't use web brower on the client side, and if they were written in a non IPv6 friendly way, they may break when DirectAccess is used, these can be VoIP phones, and also OCS. 2.Protocols that have problems with NAT traversal. These applications would usually have a dedicated data channel which is opened from the server to the client (e.g. FTP). Since NAT is quite popular in IPv4, and many times clients are behind a firewall, many protocols have a "fallback" mechanism to HTTP/HTTPS - if the main protocol fails. I would take the feedback about the need for a list. Obviously I can't publish a list here with all the protcols, but you can try and sniff the traffic and check how the protocols behave. If you have a question about a specific protocol (preferably an MS one :-) ) - let me know and I'll try and get back with an answer. Hope this helps Ben

• Anonymous
  October 17, 2012
  Just turn off your firewall, or select the other computer(s) network adapter to the "trusted" list