Forum Discussion
Lucas_Thompson_
Historic F5 Account
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:
- 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.
- 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.
Lucas_Thompson_
Dec 18, 2015Historic F5 Account
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.