After implementing DirectAccess, remote connected clients may be unable to access resources published by Citrix XenApp. This can occur because the configuration for Citrix XenApp returns IPv4 addresses instead of hostnames to DirectAccess clients. As DirectAccess uses IPv6 exclusively for client to gateway communication, the connection fails.
To resolve this issue, it is necessary to configure Citrix XenApp to return fully qualified domain names (FQDNs) instead of IPv4 addresses. This will allow the DirectAccess DNS64 service to function properly and return an IPv6 address to the client, restoring connectivity to XenApp resources.
To configure Citrix XenApp to return FQDNs, refer to one of the following Citrix technical support articles for more information.
CTX128436 – How to Enable DNS Address Resolution in XenApp 6.x
CTX135250 – How to Enable DNS Address Resolution in XenDesktop 7.x
sohailkp
/ May 5, 2015Hi Richard , i think Xenapp 6.5 is not IPv6 aware , hence it won’t work from DA clients .Couple of months we had a requirement from one of our customer stating they need to access IPv6 devices via Web URL using IPv6 address , all users were on Citrix HSD on Xenapp 6.5 , but however the URLs were not working from HSD , i had a call with citrix and they said Xenapp 6.5 is not IPv6 aware hence it won’t work – if you need to fulfill this requirement then Xendesktop 7.5 needs to be deployed . We deployed new citrix farm on 7.5 and post that all IPv6 related url’s were working fine from HSD.
currently I have mixed environment with Xenapp 6.5 and Xendesktop 7.5 farms , from direct access client i am not able to launch any HSD which are hosted on 6.5 , however Xendesktop 7.5 HSD’s works fine!
Please let me know if it worked for you in 6.5 farm , may be i am missing something here
Richard Hicks
/ May 9, 2015The client application doesn’t necessarily have to be IPv6 aware to take advantage of DirectAccess. It simply needs to leverage standard hostname resolution processes instead of making calls directly to IPv4 addresses. If the client is configured to use hostnames, it will use DNS to resolve them and for DirectAccess, the DNS64 service translates IPv4 addresses from the corpnet to IPv6 addresses used by DirectAccess clients. So, in this case, Citrix XenApp 6.5 *should* work over DirectAccess if configured correctly. However, I don’t have a test environment that I can test this conclusively, but this procedure applies to other applications that I’ve resolved using this technique.
simon harris
/ June 8, 2016Hi – we have an intranet page creating ica files. This works on LAN fine but when we connect using DA the ica file gets created, but the citrix receiver (4.4.1000.16) hangs on connection in progress.
telnet to the servers on 1494 and 2598 are successful, nat64 over iphttps tunnel responds wiht the correct IPv6 address… any ideas?
Richard M. Hicks
/ June 11, 2016Take a close look at the ICA file. If it returns an IPv4 address, it won’t work with DirectAccess. It must be configured to return an FQDN, which is a setting on the Citrix XenApp server.
Simon Harris
/ June 11, 2016Hi yes I’ve already checked this and returns the fqdn of the servers. 🙁
Richard M. Hicks
/ June 12, 2016Not sure then. You’ll probably have to perform a network trace from the client to see how the application is behaving. You can use the Microsoft Message Analyzer and choose the Loopback and Unencrypted IPsec option to monitor traffic inside the IPsec tunnels.
Alistair Hoppe
/ November 10, 2016I have tried to apply this setting to our XenApp 6.5 farm. When the setting are applied the Apps work through Direct Access, but this then breaks the communication from the XenApp servers to our license server and XenApp servers losing their license. Servers are Streamed via PVS from one image and the License server setting are applied via GPO. Have you seen this before or can you point me in a direction to a fix?
Richard M. Hicks
/ November 10, 2016That’s unusual, and something I’ve never encountered myself. Can’t imagine why returning an FQDN in the ICA file would prevent your XenApp servers from licensing correctly. Quite odd, for sure.