scarpozzi_82104
Jun 06, 2012Nimbostratus
10.2.3 Persistence Profile inconsistencies
I have a web portal deployed that is behind a pair of F5s. There are 3 web servers being load balanced that require persistence because there's no central session broker for the portal system.
Because of the way the web guys wanted to deploy the portal, it was done in mixed-mode SSL, meaning, the users go to are redirected to and are redirected back to after they authenticate correctly.
Something like 90-95% of the time, this seems to work and their sessions stay together. The other 5-10%, they start on one web server and end up on a different one. Then their sessions get locked on the web servers and they can no longer login until they time out (long time outs too).
To do this, I have to have 2 pools and 2 virtual servers (http and https) and match across virtual servers.
The number of calls about this problem showed up pretty quickly and it appears the upgrade to 10.2.3 from 10.2.0 may be the culprit. I found this in the release notes prior to 10.2.3:
Behavior changes in 10.2.2
ID 226971, CR142479
In previous releases, the system reused client session IDs from previous sessions to reestablish SSL connections. Now, in situations where security changes in the BIG-IP configuration, for example, an iRule changes the security parameter to request or require client certificates, the system establishes a new SSL connection with the client and does not reuse the previously established session ID.
So...my question. Could that be the cause of a Source IPAddress Affinity profile not working?
I plan on rolling back to 10.2.0 and seeing if the problem goes away. I just wanted some more eyes on the problem to assist since I've not gotten much feedback from Support over the past many weeks and numerous tcpdumps showing the behavior. They've really tried though-
Thanks,
Scarpozzi