none
UAG DirectAccess and Citrix - unable to launch applications RRS feed

  • Question

  • Scenario:
    Single UAG server with UAG patch 1
    IPv4 only inside
    XenApp 4.5 and XenApp 6 servers
    No Citrix Secure gateway
    Citrix online plugin 12.036

    Outlook/file access/etc works, and we're able to access the XenApp web interface.
    Launching Citrix application fails: "Unable to launch your application. Contact your help desk with the following information: Cannot connect to the Citrix XenApp server. There is no Citrix XenApp server configured on the specified address."

    We've tried editing an ica file and entering hostname, fqdn, ipv4 and ipv6 as the XenApp desktop address, but all results in the same error message. And it doesn't matter which server or application we try to access.

    Does ICA work at all through UAG DA with NAT64/DNS64? Do we need Ctirix secure gateway?

    I hope anyone out there has some experience with this :)

    David

     

     

    Friday, June 4, 2010 12:49 PM

Answers

  • I think the best method to implement it in the "DirectAccess way" is to deploy the CSG on the internal network.

    I really don't know if IPv6 is required in this case, but if it is and you don't want to enable ISATAP, there are other ways to create an IPv6 connectivity between the servers.

    First make sure that an IPv6 address is a must in this scenario.

    If it is, you can create a Point to Point tunnel between the UAG box and the CSG.

    • Run netsh int ipv6 add v6v4tunnel on both servers. this will create a link-local IPv6 tunnel, based on IPv6 connectivity
    • Set these new interfaces as forwarding.
    • Create a global IPv6 address on the CSG (make sure this address is within the organizational prefix - the endpoint in the 2nd IPsec tunnel rule)
    • Add routes to this global address in the UAG box on the newly created interface.
    • Add a default route to the UAG box's in the CSG on the newly created interface

    Let me know if you need any help

    • Marked as answer by Erez Benari Wednesday, June 16, 2010 11:53 PM
    Thursday, June 10, 2010 6:55 AM
  • Guys,

      I've got this working in a lab. Here's how:

    1. You need Citrix Secure Gateway. I turned on ISATAP using DNS, but you could enable ISATAP on the CSG only by editing the hosts file and adding an entry with the UAG's internal address and the name ISATAP. This way you will not affect the whole network.

    2. We configured the web interface to point to the CSG by name (see your Citrix manual)

    3. We needed to add the NRPT rule which resolves the CSG name on the internal DNS server

    The reason why the Citrix client requires 3 to work is unclear. The only difference we know of between adding and not adding the rule is that when you add the rule, it is possible to retrieve an A record (IPv4 address) as well as the IPv6 address. I'm in contact with Citrix to figure this out.

    Thanks to Citrix and to Björn Wikzell for the help.

    Regards,

    Noam

     

    • Marked as answer by Erez Benari Wednesday, June 16, 2010 11:53 PM
    Thursday, June 10, 2010 11:24 AM

All replies

  • Hi David,

    I'm finding the same thing here. I've also posted a follow up to someone else here , but no response yet.

     

    Seems to be a common issue. Xenapp web interface works, and can enumerate all of the apps, but trying to connect to the presentation server fails.

    Let me know if you get any further, I would really appreciate it, or let me know if you'd like to exchange notes.

     

    Cheers,

    Matt

    Friday, June 4, 2010 3:42 PM
  • Hi Amigo. DirectAccess always use IPv6. UAG makes the trick with internal servers not running IPv6. UAG sends a ficticious IPv6 address to DA clients when internal servers are IPv4 only. So, when DA client resolves the name of an internal server, it always get an IPv6 address and it seems that Citrix Client doesn't deal well with IPv6 addresses. Maybe using secure gateway could work.

    Hope it helps


    // Raúl - I love this game
    Friday, June 4, 2010 7:42 PM
  • Hi,

    The Citrix Secure Gateway is a free product for anyone who has XenApp and XenDesktop. This application supports IPv6 communication with the client.

    We recommend deploying a Citrix Secure Gateway behind the UAG DirectAccess server, and have the clients talk to the gateway over IPv6.

    Please contact Noam for more information. noamb@microsoft.com

    Thanks,

    Yaniv

    Sunday, June 6, 2010 4:33 PM
  • Can you confirm that CSG works from a DA client in an IPv4-only network? I saw some posts indicating that the CSG server would need IPv6, and since this is a fairly complex network I can't just enable ISATAP.

    And even if CSG is a free product, it's not free to design, implement and maintain for an organization with 4000 users. But it seems like this will have to be my recommendation to the customer, seeing as there's no official response from Citrix or Microsoft on this yet - probably arguing over who's to blame :)

    Matt: I saw the thread on forefrontsecurity, but wanted to ask here as well. We might create a PSS case for this, if we do I'll update both threads with the results.

    David

    Monday, June 7, 2010 8:34 AM
  • You can contact Noam in the email address I specified above.

    He's in charge of App Compatibility in UAG DirectAccess. I believe he has all the information you need.

    Monday, June 7, 2010 10:18 AM
  • We already had a public facing CSG server, so I just added this public URL to the NRPT exemption list...this worked well for me...
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Monday, June 7, 2010 2:40 PM
    Moderator
  • OK, here's what I've gathered so far:

    * Citrix applications does not work over UAG DA out of the box.
    Apparantly this is because of a security function on XenApp which discovers that the packets have been modified between the client and the server (by NAT64) and so discards them.
    This is second-hand information via a collegue, but from a trusted source (John Craddock), so I unfortunately don't know anything else about this security function, not even what it's called.

    * This security function can be turned off in XenApp 6, but you might not want to for obvious reasons.

    * You can use Citrix Secure Gateway for DA clients
    This apparently requires IPv6 on the CSG.
    According to forum posts it also requires that you add an exception in NRPT pointing citrixapps.domain.internal to internal DNS server. Can't quite see why, but I'm guessing NAT64 is somehow triggered when UAG DNS is used, even if the original address is IPv6.

    * You can use CSG externally as Jason pointed out
    This could well be the best solution since it won't affect the infrastructure in any way.

    I'll have to test the various solutions properly at the office since testing on a customer's production environment is a bad thing :)

    Thanks for all the help!
    David

    Tuesday, June 8, 2010 7:57 AM
  • Forgot one thing:

    XenApp 6 on Windows 2008 or R2 with IPv6 should also work, probably with an NRPT exception as well.

    David

    Tuesday, June 8, 2010 8:08 AM
  • You only need the NRPT exception if you want communication to go OUTSIDE the DA tunnel. This is valid when you are using an external facing CSG deployment, but not if you are using an internal one.

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, June 8, 2010 8:51 AM
    Moderator
  • P.S. My CSG is not using IPv6, but is external facing. 
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, June 8, 2010 9:00 AM
    Moderator
  • You only need the NRPT exception if you want communication to go OUTSIDE the DA tunnel. This is valid when you are using an external facing CSG deployment, but not if you are using an internal one.


    Well, not according to these forum posts where they solved it by pointing to internal DNS servers:
    http://forums.citrix.com/message.jspa?messageID=1421545
    http://forums.forefrontsecurity.org/default.aspx?g=posts&t=378

    This is why I need to test things for myself, I just can't see the reason for using internal DNS directly when it returns the same IPv6 address as UAG DNS :)

    David

    Tuesday, June 8, 2010 10:12 AM
  • Sorry, bad terminology on my part...by NRPT exception I mean bypassing DA completely and using public DNS entries. You can also configure the NRPT to provide internal DNS server responses without using the DNS64 feature of UAG, as indicated in those articles. I guess this could work too...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, June 8, 2010 10:37 AM
    Moderator
  • I agree with Jason.  For services that have methods of connecting remotely, I would think you are better off using that remote connection rather than trying to tunnel it over DirectAccess to pseudo-connect internally.  It just adds another level of complexity and likely would increase latency too.  For example, you wouldn't want to use Outlook Web Access over DirectAccess.  Instead you would expose OWA to the web and exclude that server from DA so your clients connect to the external interface rather than tunnel over the UAG server and to the internal side of things.

    To exclude the server (forgive me if you already know how, just want to be thorough) open the Forefront UAG MMC and Edit the Infrastructure servers.  On the second page is DNS suffixes.  Just scroll to the bottom of the list and double click the last line.  Select "Specific Server", enter the FQDN and then select "Do not use an internal DNS server for the specified server of suffix."  Click OK and finish the wizard.  don't forget to click "Generate Policies" and then Activate the configuration from the File menu.

     


    MrShannon | TechNuggets Blog | Concurrency Blogs
    Tuesday, June 8, 2010 9:06 PM
  • Yep, that's what I normally do with OWA and such in my DA installations, but in this case Citrix is only available externally through the existing SSLVPN/publishing solution (Juniper), which uses two-factor authentication and thus cannot provide single sign-on for citrix apps from DA clients.

    David

    Wednesday, June 9, 2010 8:27 AM
  • Ok, let us know what you go with in the end?
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, June 9, 2010 8:41 AM
    Moderator
  • Dear David,

    We are running a very similar scenario and we have a successful connection with Presentation Server farm (we are using version 4.5).

    No need for Citrix Secure Gateway. Only UAG 2010 Up1 and the Presentation Server farm.

    With assistance from MS, we set up a HTTPS trunk.

    Using this URL as reference: http://blogs.technet.com/b/edgeaccessblog/archive/2010/03/25/how-to-publish-citrix-xenapp-5-x-with-uag-2010.aspx.
    And ensuring that the URLs were allowed on the Trunk configuration.

    Windows Client version 12: Works
    Linux and Mac OS Client version 11: Does not work. (We did not implement all the steps listed on the aforementioned URL).

     

    Best regards,
    Tarso

     

    Wednesday, June 9, 2010 8:58 PM
  • We are talking about using Citrix with UAG DirectAccess, not a UAG portal...
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, June 9, 2010 9:42 PM
    Moderator
  • I think the best method to implement it in the "DirectAccess way" is to deploy the CSG on the internal network.

    I really don't know if IPv6 is required in this case, but if it is and you don't want to enable ISATAP, there are other ways to create an IPv6 connectivity between the servers.

    First make sure that an IPv6 address is a must in this scenario.

    If it is, you can create a Point to Point tunnel between the UAG box and the CSG.

    • Run netsh int ipv6 add v6v4tunnel on both servers. this will create a link-local IPv6 tunnel, based on IPv6 connectivity
    • Set these new interfaces as forwarding.
    • Create a global IPv6 address on the CSG (make sure this address is within the organizational prefix - the endpoint in the 2nd IPsec tunnel rule)
    • Add routes to this global address in the UAG box on the newly created interface.
    • Add a default route to the UAG box's in the CSG on the newly created interface

    Let me know if you need any help

    • Marked as answer by Erez Benari Wednesday, June 16, 2010 11:53 PM
    Thursday, June 10, 2010 6:55 AM
  • Guys,

      I've got this working in a lab. Here's how:

    1. You need Citrix Secure Gateway. I turned on ISATAP using DNS, but you could enable ISATAP on the CSG only by editing the hosts file and adding an entry with the UAG's internal address and the name ISATAP. This way you will not affect the whole network.

    2. We configured the web interface to point to the CSG by name (see your Citrix manual)

    3. We needed to add the NRPT rule which resolves the CSG name on the internal DNS server

    The reason why the Citrix client requires 3 to work is unclear. The only difference we know of between adding and not adding the rule is that when you add the rule, it is possible to retrieve an A record (IPv4 address) as well as the IPv6 address. I'm in contact with Citrix to figure this out.

    Thanks to Citrix and to Björn Wikzell for the help.

    Regards,

    Noam

     

    • Marked as answer by Erez Benari Wednesday, June 16, 2010 11:53 PM
    Thursday, June 10, 2010 11:24 AM
  • OK, here's what I've gathered so far:

    * Citrix applications does not work over UAG DA out of the box.
    Apparantly this is because of a security function on XenApp which discovers that the packets have been modified between the client and the server (by NAT64) and so discards them.
    This is second-hand information via a collegue, but from a trusted source (John Craddock), so I unfortunately don't know anything else about this security function, not even what it's called.

    * This security function can be turned off in XenApp 6, but you might not want to for obvious reasons.

    * You can use Citrix Secure Gateway for DA clients
    This apparently requires IPv6 on the CSG.
    According to forum posts it also requires that you add an exception in NRPT pointing citrixapps.domain.internal to internal DNS server. Can't quite see why, but I'm guessing NAT64 is somehow triggered when UAG DNS is used, even if the original address is IPv6.

    * You can use CSG externally as Jason pointed out
    This could well be the best solution since it won't affect the infrastructure in any way.

    I'll have to test the various solutions properly at the office since testing on a customer's production environment is a bad thing :)

    Thanks for all the help!
    David


    You statet that you can disable this security feature on XenApp 6

    Please tell me where. I do not have any idea, which function you mean and how I can disable it.

    Please give an advice.

    Thanks for your help!

    Stephan

    Wednesday, February 29, 2012 5:10 PM
  • Hi All,

    Sorry to dig up an old thread but I'm experiencing a similar issue to the rest of you.

    I have some remote sites that use a combination of Direct Access 2012 and a regular WAN connection. The users are frustrated about being forced to use two seperate methods of accessing there published apps.

    Clients on Direct Access have to connect via public CSG but when they are connected to the LAN the connection is via a pnagent/web interface setup. We are using Web Interface 4.6 and Xenapp Plugin 11.0.0.5357. I would like to use this same method of connection when users are on Direct Access.

    The client can connect to the Web Interface using the Xenapp plugin and it can enumerate apps but it appears to be using direct TCP/IP rather than DNS or FQDN to connect?

    Any ideas on how to get the apps working? I've tried a couple of different things like tweak config files and using proxies but no joy yet.

    Cheers,
    Chris

    Tuesday, July 23, 2013 4:53 AM
  • xSwadSx,

    why don't you let users use the WI address instead of the CSG address? You can add an entry to the web interface site under the topic "secure access" and redirect packets from the DirectAccess server to use "Gateway Direct" instead of "Direct". But do not remove the "Default" entry for all others.

    (Sorry, I cannot upload screenshots to here, but you can use this address to see what I mean: http://flic.kr/s/aHsjH2BCCY )

    If packets come from 172.25.192.248 or from 172.20.192.90 (internal IPv4 address of the DirectAccess server) the proxy eucag01.contoso.de will come into account as an ICA proxy. All others will use the WI in direct mode without the ICA proxy.

    Users will use the same address for the web interface even over DirectAccess. This works if the access is IPv4 only on the intranet (NAT64/DNS64).

    regards,

    Stephan

    Tuesday, July 23, 2013 6:28 AM
  • Thanks Stephan,

    That could work. I'll give it a try and let you know how I get on.

    Cheers.

    Tuesday, July 23, 2013 10:52 AM
  • Hey Stephan,

    Thanks for your suggestion it worked via a browser but not via the WI/Pnagent.

    I used a similar method to get Direct Access working via the WI/pnagent. I had to modify the webinterface.conf file under the PNAgent site. Little bit concerned that this is not a supported method of doing this but it has worked none the less.

    For anyone who is interested here is the config I replaced:

    ClientAddressMap="da internal interface ip"/255.255.255.255,SG,*,Normal
    ClientProxy=*,Auto,-
    # CompanyHomePage=[URL of your company home page]
    CompanyLogo=../media/citrix.gif
    CredentialFormat=All
    CSG_EnableSessionReliability=Off
    CSG_Server="csg.contoso.com.au"
    CSG_ServerPort=443
    CSG_STA_URL1=http://"sta.contoso.com"/scripts/ctxsta.dll

    Cheers,

    Chris


    • Edited by xSwadSx Wednesday, July 24, 2013 1:25 AM Typo
    Wednesday, July 24, 2013 1:24 AM