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:
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:
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
A common question I see on the message boards and in conversations with our DirectAccess customers relates to the IPv6 transition technology interfaces that are active on the DirectAccess client at any point in time. Most often, the question comes up about why both the Teredo and IP-HTTPS interfaces are active at the same time. And when they are both active, which one is actually being used to transfer information between the DirectAccess client and UAG DirectAccess server?
I wondered the same thing for a long time – but the answer was available in the TechNet library and I didn’t even know it. The following is from the TechNet entry DirectAccess Client Connection is Slow which you can find at http://technet.microsoft.com/en-us/library/ee844161(WS.10).aspx :
“The DirectAccess client needs to determine which of these two transition technologies to use. IP-HTTPS and Teredo both attempt qualification of their interface state at the same time. If the Teredo interface is qualified, the IP-HTTPS client waits in an offline state for a computed delay for the DirectAccess client to detect corporate connectivity. The computed delay is either ten seconds or a network delay larger than ten seconds based on the round trip time of TCP packets from the client to the public IPv4 address of the DirectAccess server. If the DirectAccess client detects corporate connectivity within this network delay, the IP-HTTPS client will remain in an offline state. If the DirectAccess client does not detect corporate connectivity within this network delay, the IP-HTTPS client will attempt to qualify again.
Using IP-HTTPS for DirectAccess connectivity has higher overhead and lower performance than Teredo. If the DirectAccess client is using IP-HTTPS instead of Teredo, the DirectAccess client will have a lower performance connection.
However, due to network timing issues, it is possible for the DirectAccess client to have both Teredo and IP-HTTPS interfaces active, but use only the IP-HTTPS interface for traffic to the intranet. This condition occurs when the DirectAccess client takes more than the computed delay for the DirectAccess client to determine corporate connectivity over the Teredo interface. To test for this condition, run the ipconfig command at a command prompt. If you have global addresses on both the Teredo and IP-HTTPS tunnel interfaces, this condition has occurred.”
So there you have it. The Teredo and IP-HTTPS interfaces will both come up if corporate connectivity isn’t detected within the specified time interval. And when you see both interfaces active, it’s the IP-HTTPS adapter that’s passing the traffic.
For more information about Corporate Connectivity checking, see:
http://technet.microsoft.com/en-us/library/ee382273(WS.10).aspx
http://blogs.technet.com/b/edgeaccessblog/archive/2010/05/09/the-mystery-of-the-ip-https-listener-an-outlook-client-and-an-ipv4-only-network.aspx
It’s done! The last in the set of UAG DirectAccess Test Lab Guides (at least for now, the effort is a continuous one).
If you haven’t heard about our Test Lab Guide efforts, check out:
http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
In the troubleshooting UAG and NAP Test Lab Guide we go through a number of DirectAccess and NAP scenarios where we break something in the configuration and then use a number of DirectAccess and NAP troubleshooting tools to see what their output looks like when things get broken. Its a great way to get familiar with these tools and develop skills on how to troubleshoot problems with NAP in a UAG DirectAccess environment.
You can download the Troubleshooting UAG DirectAccess with NAP Test Lab Guide over at:
http://www.microsoft.com/downloads/details.aspx?FamilyID=e4037e34-09e7-41ab-a6d9-029394eb2d3d&displayLang=en
We also have a Troubleshooting UAG DirectAccess Test Lab guide which walks you through a number of scenarios where you break various components of UAG DirectAccess and then use a number of tools to solve the problem. It’s a fantastic way to learn some of the inner workings of DirectAccess and enables you to get that critical hands-on experience you need to troubleshoot UAG DirectAccess problems. You will learn something new about DirectAccess after going through this Test Lab Guide!
You can download the Troubleshooting UAG DirectAccess Test Lab Guide at:
Check out these Test Lab Guide and let me know what you think. We have other Test Lab Guides and we keep a clearinghouse of the available Test Lab Guides on the TechNet wiki. To see a list of currently available Test Lab Guides, head on over to:
http://social.technet.microsoft.com/wiki/contents/articles/test-lab-guides.aspx
If you have an idea for a new Test Lab Guide for us to put together, then let me know! Send a note to tomsh@microsoft.com and put in the title New Test Lab Guide Suggestion. Or, if you think you can do a better job, write your own Test Lab Guide extension on the wiki.
Also, if you have any questions about the UAG DirectAccess Test Lab Guides, please feel free to post questions on the UAG DirectAccess forum over at:
http://social.technet.microsoft.com/Forums/en/forefrontedgeiag/threads
I’ve always recommend that you when learning about DirectAccess that you begin your trek with the UAG DirectAccess Test Lab Guide over at http://www.microsoft.com/downloads/details.aspx?familyid=CEEBFF8D-CDF9-4AFA-8DAA-918CDC884DC0&displaylang=en
However, I know there are a lot of cowboys out there (heck, I’m one of them) and often we want to try things out on a live production network just too see how it works. Then when things don’t work, we’ll go to the Test Lab Guides to figure out what didn’t work by creating something that’s known to work. That’s what the Test Lab Guides are all about!
I was talking to one of my “cowboy” friends a couple of weeks ago and he was telling me that he was having some problems getting IP-HTTPS working. His 6to4 configuration was working fine and DirectAccess connectivity was working through both the intranet and infrastructure tunnel.
Take a look at the figure below. What he did was create a DMZ behind his firewall that used public addresses so that he could test 6to4. This will work if the DA client is located between the firewall and the UAG DA server, but wouldn’t work from the Internet. That was OK, since he wasn’t trying to make it work from the Internet yet – he just wanted to do some live testing.
Key components of the configuration:
At this point can you figure out why his IP-HTTPS adapter wasn’t firing up?
The answer is that since the DA client in the DMZ was assigned a public DNS server address, and that there is a server that is authoritative for the domain.com domain that included a host record for uag.domain.com, the DA client tried to connect to the actual internet based server with that name and not the UAG DirectAccess server that he configured as his test DirectAccess server.
So if you want to be a cowboy and not start with the Test Lab Guides, then watch out for DNS issues! Or, you can take your momma’s advice
BTW – you can always ask questions about DirectAccess and Test Lab Guides over on the TechNet forums over at http://social.technet.microsoft.com/Forums/en-us/forefrontedgeiag/threads
Tom Shinder tomsh@microsoft.com Microsoft ISD 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
One of the most difficult decisions you have to make as an administrator and network engineer is to decide how you’re going to allocate your limited time to evaluating new products and technologies. There are so many other things you need to do. So when you make the decision to try out a new technology you’re actually taking a significant risk and gambling with your time.
If you win, you’ll be the hero and can begin long process that goes toward a production deployment. If you lose, you’ve wasting many hours on something that you thought sounded good, but ended up not getting it to work.
I feel that pain and have felt that pain in the past. One thing that has created a lot of pain for me was trying to figure out how to do a proof of concept test of a new and complex technology. While I might have figured out how to make the thing work in a test lab, it’s an entirely different ball of yarn to translate that test lab experience to a useful proof of concept.
So I put my thinking cap on and asked around to get some ideas on how to create a proof of concept lab guide that would provide a simulated environment that could closely mirror what you would do in a “live” proof of concept, where you might have 10-20 people from the IT group and maybe some power users from the employee base to participate in.
What I came up with was a UAG DirectAccess Proof of Concept Lab Guide that would walk you through the steps of putting together a proof of concept test lab. The goals of the POC lab guide were:
A key issue with the POC guide is that we wanted to break out the UAG DirectAccess forest from the production forest. There are a few reasons for this:
After you finish the POC lab guide you’ll have a much better understanding of how you might approach the deployment of a limited POC. After completing the POC you’re ready to start a larger pilot program – where more users are involved and the machine accounts are in the production forest instead of the UAG DirectAccess forest.
You can find the UAG DirectAccess POC guide over at:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2ba2e429-1385-4253-9667-63c2c85747e7
Finally, I have to tell you that the POC lab guide isn’t built to the Test Lab Guide specifications that I talk about over at http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx The reason for this is that I created this document before we had hammered down the TLG concept. I could have back-ported the POC guide but given that the Base Configuration is really focused on a single forest concept and we have two forests for the POC, I decided that it would be OK to not back port it to TLG specs. However, if you’re really interested in the POC guide, but desperately want to take advantage of your existing Base Configuration snapshot – then I’ll take the time and make v2 consistent with the TLG design.
Let me know what you think and as always, you’re welcome write to me if you want any questions about the POC guide or if you’re having problems getting it to work. Also, if there are any other TLGs (all future TLGs will be written to the TLG spec) you’re interested in, let me know!
In order for SSTP (Secure Socket Tunneling Protocol) and DirectAccess to work properly the SSTP and DirectAccess client must have access to the CRL (Certificate Revocation List) of the server certificate (if you are using Client Certificate or Smart Card authentication you will also need access from the client to the CRL)
If you are using internal Microsoft Certificate Authority (CA) you can publish the CRL through UAG based on the following procedures:
Important Note: If you are using Microsoft Certificate Authority (CA) make sure the Root CA certificate (If you are using in intermediate CA, also include the intermediate CA certificate) is located in the Trusted Root Certification Authorities of the Local Computer Store
Open UAG management Console, navigate to HTTP Connections, right click, and choose New Trunk
On the Welcome to the Create Trunk Wizard page click Next.
On the Step 1 – Select Trunk Type page, select the Portal trunk option and click Next.
On the Step 2 – Setting the Trunk page, enter the Trunk name and enter the Public host name, this part is very important! You must enter the exact URL that you configured in the CDP (CRL Distribution Point) setting on your certificates, then click Next.
Note: External clients must be able to resolve the public host name
On the Step 3 - Authentication page, choose any authentication repository (this is not relevant because in next phases we will disable the authentication for this Trunk because access to CRL doesn't require authentication) then click Next.
On the Step 4 – Endpoint Security page, click Next (you will disable Endpoint Security for this Trunk later so the choice made her is immaterial).
On the Step 5 Endpoint Policies page click Next.
On the Completing the Create Trunk Wizard page click Finish.
Now we will configure an Other Web Application (application specific hostname) application in the new trunk to publish the internal CRL.
In the UAG management console click Add.
On the Step 1 – Select Application page select the Web option and then select the Other Web Application (application specific hostname) option from the drop down list. Click Next.
On the Step 2 – Configure Application page enter the Application name and in the Application type text box, enter OtherWeb, then click Next.
On the Step 3 – Select Endpoint Policies page click Next.
On the Step 4 – Deploying an Application page click Next.
On the Step 5 – Web Servers page, in the Addresses text box, enter the name on your internal IIS server that hosts the CRL. Change Paths to the path defined for CRL Distribution Point, for example “/CertEnroll/* (your certificate distribution point will likely have a different name, enter the name that you have defined for your CDP). Define the Public host name as configured in the CDP (CRL distribution point). This name should be the same Public host name defined for the trunk. Click Next.
Note: External clients should be able to resolve this name
On the Step 6 - Authentication page click Next.
On the Step 7 – Portal Link page click Next.
On the Step 8 - Authorization page click Next.
On the Completing the Add Application Wizard page, click Finish.
In the UAG Management Console navigate to the Initial application and choose the application you created (this will allow access directly to the CRL and not through the UAG default portal).
In the UAG Management Console navigate to Trunk Configuration and choose Configure
Disable Require users to authenticate at session logon onthe Authentication tab in the Advanced Trunk Configuration dialog box.
Enable the option “Disable component installation and activation” on Sessions tab of Advanced Trunk Configuration dialog box. You need to do this because UAG client components are not required for publishing CRL. Also enable the option “Disable scripting for portal applications”
This article was originally written by Tarun Sachdeva, Sr. Support Engineer.