Forum Discussion

Jose_Nelson_206's avatar
Jose_Nelson_206
Icon for Nimbostratus rankNimbostratus
Dec 17, 2015

Citrix Receiver thick clients fail to connect through APM

We have a new Citrix XenApp configuration on our F5 that we setup using the latest iApp. We're using APM. Via a browser, from any OS, it's working fine. The only issue we have is that Android, IOS or any Citrix Receiver client that runs on Mac or Windows fails to connect. The Windows Receiver client gets the error, "Citrix Receiver could not log you on to the store."

 

Some notes: -On the APM VS, we have a clientssl and serverssl profile.

 

-The SSL handshakes, client-side and server-side, complete successfully. -The XenApp front end server (pool member) never ever tried to talk to the XML broker VIP. -The APM log shows: err vdi[24769]: 01490000: {ca9.C} Error parsing version from response: 'TTP/1.1 ' -Yes, the error above is missing an "H" (that's not a typo). Does that mean anything? -I disabled the use of DHE and ECDHE so that I could decrypt the conversation. However, for some reason I can't decrypt and see the data on the serverssl side to see the response from the pool member. It's after that response that the connection is RST.

 

Any thoughts on how to proceed with this would be appreciated.

 

APM
application delivery

4 Replies

Sort By
  • Lucas_Thompson_'s avatar
    Lucas_Thompson_
    Historic F5 Account
    Dec 17, 2015

    You'll need to either decrypt it, or just set it to communicate on port 80. Citrix servers generally allow the comms to be 443 or 80.

     

    The SSLDUMP we use is generally the same as the normal ssldump, so the use (and how to decrypt it) is the same. Two rules:

     

    1. Make sure the SSL session cache is deleted so you get a new SSL session ID, otherwise the decryption can't work. In your case this would be for the serverssl profile, not the clientssl profile because you're trying to decrypt the serverside of the connection.
    2. As you've done, DH ciphers have to be disabled.

    I see that you have a support case on this already. As soon as we can see the backend comms, we'll have a better idea about what's happening. I can't find any reference to this error in any other support case except one where somebody was trying to get VMWare Horizon View to function via APM. The symptoms for that one were nearly identical (including the 'TTP /1.1' part) but it doesn't look like there was any followup or resolution.

     

    • Jose_Nelson_206's avatar
      Jose_Nelson_206
      Icon for Nimbostratus rankNimbostratus
      Dec 18, 2015
      I was able to successfully decrypt the server side of the conversation. The error we were seeing in the apm.log file (err vdi[24769]: 01490000: {ca9.C} Error parsing version from response: 'TTP/1.1 ') can now be seen in the decrypted capture. We see our pool member (129.101.186.221) responding in connection 11 9 with a single "H" and in connection 11 10 is produces the rest of the response with begins with " TTP/1.1 302 Found." So we're seeing the "H" being omitted for some reason. After this response is when the conversation FIN's by the client, in this case the F5. Is this something that can be controlled via the http profile assigned to the VIP? Here is the where we see the error. The snippet of the conversation below starts with the client performing a GET: 11 8 1450457257.3673 (0.0005) C>SV3.1(208) application_data --------------------------------------------------------------- GET /Citrix/PNAgent/Config.xml HTTP/1.1 User-Agent: SelfService/4.3.100.10167 (Release) Host: vlab-pprd.uidaho.edu Connection: Keep-Alive X-Forwarded-For: 129.101.169.48 --------------------------------------------------------------- 11 9 1450457257.3697 (0.0024) S>CV3.1(32) application_data --------------------------------------------------------------- H--------------------------------------------------------------- 11 10 1450457257.3697 (0.0000) S>CV3.1(448) application_data --------------------------------------------------------------- TTP/1.1 302 Found Cache-Control: private Content-Type: text/html; charset=utf-8 Location: https://vlab-pprd.uidaho.edu/Citrix/VLabPPRD/PNAgent/config.xml Server: Microsoft-IIS/8.5 Date: Fri, 18 Dec 2015 16:47:37 GMT Content-Length: 180 Object moved Object moved to here. --------------------------------------------------------------- 11 1450457257.3700 (0.0003) C>S TCP FIN 11 1450457257.3706 (0.0005) S>C TCP FIN
    • Lucas_Thompson_'s avatar
      Lucas_Thompson_
      Historic F5 Account
      Dec 18, 2015
      Oh, that's fascinating. So the data is in separate packets and it seems like VDI isn't re-assembling them correctly. It's weird for the server to be doing that, but technically legal. Out of curiosity, do you have some sort of L7 firewall in between the Citrix and F5 that might be doing this? One more thing is that if the packet that has the SSL data 'H' in it doesn't have the PSH flag, it may be possible to use an extra LTM VS (pool = IP of citrix, Destination = dummy IP you put into iApp config) to re-assemble it for you. It'd need to have both serverSSL and clientSSL profiles.
    • Jacob_Newfield1's avatar
      Jacob_Newfield1
      Historic F5 Account
      Dec 21, 2015
      There shouldn't be a redirect from the Storefront server for PNAgent communications, i.e. even if the parse error is corrected the overall functionality will fail. The BIG-IP/APM should be configured to translate ingress client-side requests from "/Citrix/PNAgent/config.xml" into egress server-side request "/Citrix/PNAgent/[store]/config.xml" which is accomplished via an iRule data group entry named "APM_Citrix_ConfigXML" with key/value pair "[vs_fqdn] := /Citrix/[store]/PNAgent/config.xml". The APM supports the Storefront protocol where the URI "/Citrix/PNAgent/config.xml" would not be used. However, if the PNAgent protocol is required or desired then be sure to configure the client with a case sensitive PNAgent URI, i.e. "/Citrix/PNAgent/config.xml" and not ""/Citrix/PNAgent/Config.xml".