We’ve seen a lot of questions on how to get the Citrix client to work with DirectAccess. The following provide some information and procedures that may work to get the Citrix client to work over DirectAccess.

The Citrix client can use IPv6 to connect to one type of server only: the Citrix Secure Gateway (CSG). In order for the Citrix client to work over DA, you need to:

1. Install the CSG on the internal network
2. Configure the Citrix Web Interface to use CSG
3. Create an NRPT rule that uses the internal DNS server directly instead of going through the UAG DNS64

A key issue to be aware of is that Citrix clients do not support IPv6, with the exception of connecting to the Citrix Secure Gateway (CSG). Although it can sit directly on the internet, it’s preferred that it be put it on the LAN, with an IPv6 address (either native or ISATAP). Here’s how it works:

1. The client establishes a DA connection
2. The user uses the browser to bring up the Citrix Web Interface and authenticates to it.
3. The Web Interface compiles a list of allowed applications and presents them to the user.
4. The user clicks an icon that represents an application and the Web Interface invokes the client side Citrix plug-in
5. The Citrix plug-in initiates a session with the server through the CSG according to the connection information supplied by the Web Interface. In this case this includes information about the SSLProxy (CSG) and Secure ticket authority.

In configuring the CSG, note should be taken in http://support.citrix.com/proddocs/index.jsp?lang=en&topic=/xenapp5fp-w2k8/sg-features-v2.html to use the IPv6 address to listen on.

Note:
The client plug-in needs to be version 11 and above and must trust the CSG’s server certificate.

Finally, it appears that even though the Citrix client is able to connect over IPv6 to the CSG, it needs the CSG’s name to resolve to both the IPv4 address and the IPv6 address. For this to happen, we need to exempt the name of the CSG from the NRPT in the UAG DirectAccess configuration so that it uses an internal DNS server instead of the UAG DNS64. This is done by entering the IP address of the internal DNS server. Not doing this will default to the UAG DirectAccess server’s DNS64 services, which never returns IPv4 addresses (it always returns a NAT64 address), causing issues for the Citrix client.

An example of how you can configure this is included in the figure below.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Microsoft DAIP iX/SCD iX
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

While I spend most (all) of my time working with the UAG DirectAccess solution, UAG DirectAccess is functionality essentially represents a superset of Windows DirectAccess functionality. Therefore, I thought it might be interesting to share with you all some questions I received from a fellow who is interested in deploying Windows DirectAccess. Maybe the questions and answers contained here will help you with your own planning for deploying DirectAccess in your SMB environment.

==============================

Question/issue 1:
I’m in the process of putting together a DirectAccess solution for a small client of mine that needs the features of DirectAccess but can’t lay down the cash for multiple physical servers or UAG.  They don’t need the additional complexities of access to IPv4 only resources as this is basically going to be a new network starting from scratch.

I know this may not be ideal from a performance perspective because of the many shared roles and limited scalability, but this is not going to be a network with many users; rather it will be a network of a dozen or so kiosks that will always be remotely connected.  I’m starting to experiment some but haven’t found many resources for the absolute simplest implementation of DirectAccess.

I will certainly be going through the test lab documentation and other papers from Microsoft regarding the set up, but I thought I’d ask just in case anyone knows of some resources I haven't found yet (or just has some good tidbits of info themselves).

My concept is this:

1. A single physical server running Win2008 R2 as the domain controller (also DNS server, DHCP server, CA, NL server, File Server)
2. A virtual server within that physical server running Win2008 R2 as the DirectAccess server
3. The server will have the appropriate dedicated physical NICs (one internal facing for the domain controller, one internal facing for the DirectAccess server, one external facing for the DirectAccess server)
4. A firewall appliance will sit in between the external NIC of the DirectAccess server and the internet connection to provide basic protection (not NAT, just firewall)
5. The remote kiosk clients will, of course, be running Win7 Enterprise

What I’d ultimately really love is a "test lab" document similar to the one  already out there from Microsoft but designed to interface with the real internet instead of a fake internet.  The document makes several references to "problems" trying to adapt that test environment into a real world scenario, but it doesn’t give a whole lot of information about what "problems" they are referring to.

ANSWER: First off, these are great questions and thanks for sending them my way. Examples of planning for real-world deployments help everyone on their trek to DirectAccess goodness.

Since your customer can’t afford UAG at this time (maybe he will in the future as the company grows), the place to start is with the Windows DirectAccess solution. You are right that you will not have support for IPv4-only resources on the intranet, and your high availability options are somewhat limited. But you recognize these conditions and we can work within these parameters.

We generally recommend that you don’t put the Network Location Server on the domain controller, especially in pure IPv6 scenarios for some reasons regarding interface timings. While I don’t have the details in front of me, I have received information from a DirectAccess PM who strongly recommends that the Network Location Server not be placed on a DC – so if you could create a VM for the NLS, that would be a good way to go.

You can put the DirectAccess server in a virtual machine. However, there are performance implications and therefore we generally recommend that you put the DirectAccess servers on physical machines. With that said, you mention that this is going to be a relatively lightly used configuration, and therefore you might be able to get acceptable performance. You’ll need to monitoring your deployment and see if you are running into processor bottlenecks.

It is good that you’re planning on dedicated NICs for the virtual and physical interfaces. DirectAccess will perform better this way.

It’s also good you recognize that the firewall in front of the DirectAccess server will perform only firewall functionality and not NAT, because DirectAccess is not supported from behind a NAT device (although it can be done with the help of a few routing tricks, but that configuration is not supported by the product group).

Windows 7 Enterprise or Ultimate is required – so you’re good with the OS on your clients. Keep in mind that these must be domain members.

Regarding the problems that we suggest with the Test Lab Guides here are a few things that I can think of:

• In the UAG TLGs, we configure a certificate template that disables CRL checking. You don’t want to do this in a production environment
• In the Windows DirectAccess TLG, I believe Joe configure the DirectAccess server to host the CRL. You wouldn’t do this in a production environment
• The IP addressing scheme we use in the TLGs for the public is based on network IDs that Microsoft owns, so you can’t use those
• I think we didn’t configure the DHCP server to assign a default gateway, you want to do that in a production environment
• The certificate bound to the IP-HTTPS listener is a private certificate in the TLGs. While you can use a private certificate (one that you generate from your own CA), most organizations are going to use commercial certificates. If you don’t use a commercial certificate, you’ll need to find a way to securely publish your CRL

With those things in mind, you can create a “live” pilot deployment. I’d recommend that you obtain a commercial certificate for the IP-HTTPS listener, and not use the CRL checking disablement steps I deployed in the UAG DirectAccess Test Lab Guides.

-----------------------------------------

Question 2:
What are the advantages/disadvantages of using a native IPv6 infrastructure (with a tunnel broker like Hurricane Electric) vs just using ISATAP?  Are there any compelling reasons to go ahead and go native (especially if the network is going to be new with no legacy devices)?

ANSWER:

ISATAP is useful if your network infrastructure isn’t IPv6 aware, since you can tunnel your IPv6 traffic over IPv4 and use your current IPv4 routing infrastructure. However, if your routing, DNS and DHCP infrastructure is all IPv6 capable, there’s no need to deploy ISATAP and I’d recommend that you go native IPv6. You will need to configure your routers (and maybe the hosts) on your network so that they know the route back to the DirectAccess clients.

In most cases that will require that you make the DirectAccess server the IPv6 route of last resort since this is the only way to get the messages back to the 6to4 DirectAccess clients – or better, you can disable 6to4 on your DirectAccess clients and they will use Teredo instead – then your routing tables will be a bit “cleaner” and you want need to make the DirectAccess server the IPv6 route of last resort.

-----------------------------------------

Question 3:
What are the security implications with opening up inbound IPv6 traffic into your network?  Since DirectAccess requires Protocol 41 traffic to be let through the firewall directly to the external NIC on the DirectAccess server, doesn't this open up some potential security issues without an IPv6 firewall in place?  Maybe I am missing something, but since Protocol 41 is encapsulating ALL IPv6 traffic in IPv4 packets isn't letting Protocol 41 traffic through essentially the same thing as having a computer directly connected to the IPv6 internet with no firewall at all?

ANSWER:

IP Protocol 41 is used to indicate that there is direct encapsulation of IPv6 packets within an IPv4 header to support 6to4. So, we’re not really allowing all IPv6 traffic through the firewall, just 6to4 traffic. Also, keep in mind that both of infrastructure tunnel and the intranet tunnel require authentication – for the infrastructure tunnel, both computer certificate and NTLMv2 authentication is required, and for the intranet tunnel, both computer certificate and Kerberos v5 authentication is required.

While all IPv6 traffic is allowed through the IPv4 tunnel – traffic to the DirectAccess server is allowed only after the client authenticates and establishes a valid IPv6 IPsec connection . We also have some Denial of Service Protection technology built into to take care of malicious users who try to take advantage of this situation, though. However, if you don’t think this is enough – you can take my earlier recommendation and disable 6to4 on the DirectAccess clients and let them use only Teredo or IP-HTTPS. Keep in mind that this is the same situation – the Teredo and IP-HTTPS clients are also encapsulating all IPv6 traffic. But the same protections still apply regarding IPsec and DoSP.

==============================

I hope you find these answers helpful and would be happy to carry on the conversation in the comments section.

Thanks!

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

For companies thinking about deploying DirectAccess, the question of whether or not you need to deploy ISATAP will invariably come up. The answer to this question is “no” and the reasons for why you don’t need ISATAP in a DirectAccess deployment are covered in my article over at http://blogs.technet.com/b/tomshinder/archive/2010/10/01/is-isatap-required-for-uag-directaccess.aspx

However, ISATAP does have a place in a DirectAccess deployment, as I discussed in that article. If you don’t have an existing native IPv6 network infrastructure in place, then you might want to consider enabling ISATAP to fully realize the “manage out” capabilities that are part of a comprehensive DirectAccess solution.

However, in all the coverage of ISATAP, I’ve left out some critical information that can help you decide on how you deploy ISATAP in your organization. It’s at this point I get to tell you that the ole “Edge Man’s” favorite food is crow. When I get to eat crow, it means I said something in public and then find out later I was wrong (or at least not entirely right). I like crow because when I eat it, it means that I’ve learned something new.

Now with that are an introduction, let’s get into what led to this “crow eating” session. If you read this blog on a regular basis, you might remember my article on using a HOSTS file entry to control which systems configure themselves as ISATAP hosts. If you didn’t see it you can check it out at http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx 

In that article, I said:

“In general, ISATAP is a good thing…”

Now that seems like a pretty benign statement, doesn’t it? I thought so. But if you look at the Intra-site Automatic Tunnel Addressing Protocol Deployment Guide at http://www.microsoft.com/downloads/en/details.aspx?familyid=0F3A8868-E337-43D1-B271-B8C8702344CD&displaylang=en you will find the following statement:

“Appropriate Uses for ISATAP on Intranets
ISATAP in Windows is not designed for production networks [italics mine]. On a production network, ISATAP should be used in a limited capacity for testing while you deploy native IPv6 capabilities. Microsoft does not recommend the use of ISATAP across entire production networks. Instead, you should deploy native IPv6 routing capability…”

Ah, well, ahem, er, kaff-kaff, aaaa.., that doesn’t really align with my comment regarding “in general, ISATAP is a good thing”.

Let me explain.

What Does ISATAP Actually Allow You To Do?

To get a better appreciation for the situation, it’s a good start to think about what ISATAP actually does. For most of us, our introduction to ISATAP is with DirectAccess. In fact, for many of us, our introduction to IPv6 is with DirectAccess. When reading about DirectAccess you see that the DirectAccess server is configured as an ISATAP router, as well as a router or relay for Teredo and IP-HTTPS. This gives you the initial impression that ISATAP must be a required component of the UAG DirectAccess solution, and that perhaps it’s a standard for all IPv6 deployments. In truth, ISATAP has limited utility and is designed to support a very specific scenario.

ISATAP is an IPv6 transition technology and is designed as a temporary solution to help you transition your IPv4 network to an IPv6 network. ISATAP enables ISATAP capable hosts to automatically assign an address to an ISATAP adapter, and to communicate with an ISATAP router to get IPv6 routing table information. The purpose of ISATAP then is to provide ISATAP capable hosts with information that enables them to connect to hosts on an IPv6 only network. That connection is made through an ISATAP router.

The ISATAP router has an interface on the IPv4 only network and a second interface on an IPv6 only network. The ISATAP router will take the IPv6 packets that are encapsulated in an IPv4 header, and forward them to the IPv6 only network by removing the IPv4 header before forwarding them. When hosts on the IPv6 only network want to connect to hosts on the IPv4 network, the ISATAP router will receive the packets, put an IPv4 header on them, and forward them to the ISATAP enabled hosts on the IPv4 only network.

When ISATAP enabled hosts on an IPv4 only network communicate with each other, they will preferentially use their ISATAP adapters to communicate. They will query DNS and if they receive both A and AAAA records, they will use the AAAA record’s address and use IPv6 to communicate with the other ISATAP enabled host on the IPv4 only network. This is done because Windows hosts that are capable of using ISATAP (Vista and above, Windows 2008 and above) use IPv6 preferentially. It doesn’t matter that the IPv6 packets are encapsulated with an IPv4 header. Keep in mind that in order to reach the ISATAP adapter on the destination host, the source host also needs the address in the A record to get the IPv4 address of the destination.

In Figure 1, you can see three networks:

• The DirectAccess clients network (which is an IPv6 only network),
• an IPv4 only network, and
• an IPv6 only network.

When a host on the IPv4 only network wants to connect to a host on the IPv6 only network, it uses routing table entries that indicate that it should use its ISATAP adapter to send the IPv6 packets to the IPv4 address ISATAP router. The ISATAP router then removes the IPv4 header to expose the IPv6 header and forwards the IPv6 packet to the host on the IPv6 network.

The UAG DirectAccess server is also configured as an ISATAP router, and it advertises IPv6 routes that ISATAP capable hosts on the IPv4 only network can use to connect to DirectAccess clients. The DirectAccess clients network (which includes network prefixes for the Teredo, 6to4 and IP-HTTPS address spaces) is an IPv6 only network. Therefore, when a host on the IPv4 only network wants to connect to a DirectAccess client, it checks its routing table and finds that it should use its ISATAP adapter to send the IPv6 packets to the IPv4 address on the internal interface of the UAG DirectAccess server. The UAG DirectAccess server (acting as an ISATAP router) removes the IPv4 header and forwards the un-encapsulated IPv6 packet to the DirectAccess client.

Figure 1

As you can see, ISATAP is used to enable connections from an IPv4 only network (meaning the routing infrastructure only supports IPv4 routing) to an IPv6 only network (meaning that the routing infrastructure supports IPv6 and the hosts on the network use only IPv6 addressing) by using an ISATAP router. The idea here is that as you transition to an IPv6 network, you will create dedicated segments devoted to IPv6 and that during this transition, you still need to enable connectivity between the “old” IPv4 only network and the “new” IPv6 only network. The transition phase isn’t meant to be indefinite and when the transition phase of the deployment is over, you’ll disable ISATAP in DNS and take down the ISATAP routers.

ISATAP and the Special Case of DirectAccess

However, DirectAccess is a special case when it comes to ISATAP and IPv6 enablement. We want you to be able to use DirectAccess now. However, we also realize that very few networks are IPv6-only at this time and that it will take several years before the predominate network protocol is IPv6. To solve this problem, we enabled the UAG DirectAccess server as an ISATAP router. For the UAG DirectAccess server, the purpose is to enable full “manage out” capability, so that management servers on the IPv4 intranet can initiate connections with DirectAccess clients. We don’t need ISATAP to support connections initiated by DirectAccess clients to IPv4 resources on the intranet because we have the NAT64/DNS64 solution.

The “manage out” scenario where management servers on the intranet initiate connections to the DirectAccess clients is a relatively limited one in terms of scope. You won’t have that many management servers that need to be able to do this (although you might want to allow Help Desk to connect to DirectAccess clients over RDP, in which case the number of hosts that need to initiate a “manage out” connection will be larger). Since you know in advance who these machines are, you might want to consider using a HOSTS file entry on these “manage out” machines instead of enabling ISATAP for your entire network using DNS. This gets around problems you might run into if you’ve decided to disable IPv6 on the computers on your network (you can find out the details of this situation in my blog post at http://blogs.technet.com/b/tomshinder/archive/2011/02/14/use-a-hosts-file-entry-to-control-isatap-host-configuration.aspx).

Conclusion

In conclusion, we can reconcile my statement that ISATAP is generally a good thing when we think about the special case of the DirectAccess. However, the purpose of ISATAP in a DirectAccess scenario is a bit different than it is when you’re using ISATAP to transition your intranet to IPv6. Because a limited number of hosts on the intranet need to be IPv6 capable to initiate connections (manage out) DirectAccess clients, there is a good argument for not enabling ISATAP in DNS (it is disabled by default) and only using HOSTS file entries on the machines that require “manage out” capability to DirectAccess clients.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

Take a look at the figures below and see if you can guess what device is in the request/response path that you don’t typically see a UAG DirectAccess deployment.

First, the ipconfig output on a DirectAccess client located behind a NAT device:

Figure 1

Now let’s ping DC1:

Figure 2

Now let’s do a tracert from CLIENT1 and DC1:

Figure 3

With this information you should be able to figure out what the “novel” device is in the path between CLIENT1 and DC1. If you know, then consider yourself pretty well-versed with IPv6 addressing. If you don’t know, then here’s a great opportunity to learn something new!

UPDATE!

Now take a look at figures 4 and 5 and determine what device was removed from the path:

Figure 4

Figure 5

Think about the solutions and put your answer in the comments section. Give your reasoning. I’ll post the answer and a network diagram of the solution tomorrow.

Have fun!

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Forefront iX 
UAG Direct Access/Anywhere Access Group (AAG)
The “Edge Man” blog (DA all the time): http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder

We’ve received a number of questions recently about UAG DirectAccess support for the IPv6 Internet. When thinking about the IPv6 Internet, you need to think about when the DirectAccess client is on an IPv6 Internet (or on an IPv6 only intranet) and when the UAG DirectAccess server has its external interface connected to an IPv6 Internet connection.

Part of this confusion seems to stem from a TechNet article over at:

http://technet.microsoft.com/en-us/library/ee809074.aspx

Let’s look at some of the sections that might be ambiguous or otherwise difficult to understand and try to clarify a few things.

“The DirectAccess client computer connects to the Forefront UAG DirectAccess server using IPv6 and IPsec. If a native IPv6 network isn’t available (which is most probable when the user is connected to the Internet), the client establishes an IPv6-over-IPv4 tunnel using 6to4 or Teredo. The user does not need to be logged in to complete this step…”

There are two issues that need to be clarified here:

• First, the DirectAccess client always connects to the UAG DirectAccess server using IPv6 and IPsec. The IPv6 packets are protected by IPsec (with the exception of ICMPv6, which is not protected by IPsec by default). However, the IPsec protected IPv6 packets are always going to be encapsulated by an IPv4 header, using Teredo, 6to4 or IP-HTTPS (which was left out of the statement above)
• Second, if an IPv6 network is unavailable… If an IPv6 network is unavailable, then the DirectAccess client will try to use an IPv6 transition technology to connect to the UAG DirectAccess server. If an IPv6 network is available, then the machine will not be able to connect to the UAG DirectAccess server. And if somehow it does, this is not a supported scenario (I’m not saying that it can or it can’t – but I am saying that this is not a supported scenario).

That’s it – not too complicated but an important thing to know – that we don’t support scenarios where the UAG DirectAccess server’s external interface is connected an IPv6 Internet (that is to say, that the UAG DirectAccess server has an IPv6 address assigned to its external interface) and when the DirectAccess client is connected to an IPv6 only network (which prevents the client from being able to set up an IPv6 transition technology based connection to the UAG DirectAccess server.

Several people  have asked why we decided to use this approach, and the primary reason is that there are very few scenarios where the UAG DirectAccess server is connected to an IPv6 only Internet connection and where the UAG DirectAccess client is connected to an IPv6 only network. Since these scenarios can be interpreted as “corner cases” at this time, the decision was to not design toward these scenarios and focus on what we see on networks today.

That said, Microsoft is firmly committed to IPv6 and our DirectAccess design and implementation will grow with the increasing availability of native IPv6 Internet and intranet connectivity.

HTH,

Tom

Tom Shinder
tomsh@microsoft.com
Principal Knowledge Engineer, Microsoft DAIP iX/Identity Management
Anywhere Access Group (AAG)
The “Edge Man” blog : http://blogs.technet.com/tomshinder/default.aspx
Follow me on Twitter: http://twitter.com/tshinder
Facebook: http://www.facebook.com/tshinder