Cookie based session persistence with F5 BIG-IP load balancer?

[LeonW2]

Hi,

Having encountered an issue where the local client is not detected when when a VDI pool is launched from the Gateway:

"%appdata%\2XClient\ClientLog.txt" is appended "Failed to get 2XA file from IIS Server"

Support have said 2xa data is used for launching apps with native (non-HTML5) clients and that the issue is caused by the browser communicating with one gateway while the client's request for 2xa was forwarded to another. At their advice we have reconfigured our F5 BIG-IP load balancer to use cookie-based session persistence as per this article: https://kb.parallels.com/en/124412

However now that I have with a test virtual server, the client launches but the connection times out with "the specified RAS connection could not be found"

"%appdata%\2XClient\ClientLog.txt" is appended:

[T 13/00000009/T9F6C/P4F30/S0001] 04-10-19 11:08:40 - SSL Connection to [domain]:443 was successful
[E 0E/0000000B/T9F6C/P4F30/S0001] 04-10-19 11:10:40 - The specified remote RAS Connection could not be found.Verify that you have typed the correct computer name or IP address, and then try to connect again.
[E 02/00000033/T9F6C/P4F30/S0001] 04-10-19 11:12:22 - Code [02/00000006]The client could not establish a connection to the remote computer.The most likely causes for this error are:1) The servers are too busy to service your request.2) The machine is not part of the farm.

Has anyone has any experience configuring an F5 BIG-IP to work with Parallels RAS that might be able to suggest why it's not working?

Thanks,

Leon.

 

[LeonW2]

I think we've resolved it. There were 2 issues. 1. We were terminating the certificate on the F5 which malforms the initial HTTP POST, which ends up being significantly different to it being terminated on a gateway. This was breaking client detection. 2. After this we were still seeing "Status: 403 /native/get2xa/[session id]" in the HTML5GW.log. The problem was again on the f5 in that we needed to apply "source-addr-match_across_services" session persistence. Alternatively we could have load-balanced in an active-passive arrangement but this would have been a last resort.