Forum Discussion
scarpozzi_82104
Nimbostratus
Nimbostratus10.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
scarpozzi_82104I used the persistence-based cookie iRule as noted here:
https://devcentral.f5.com/wiki/iRules.Cookie_Encryption_across_pools_and_services.ashx
It appeared to help reduce the issue. (I still got errors in my logs, but they were cookie-based errors...perhaps from mis-configured browsers) I was unable to confirm any persistence problems in the logs.
Unfortunately, adding the cookie somehow broke the login sequence. This is a uPortal application and it started causing uPortal errors until I removed the iRule. The errors occurred just after the auth post when the session was to be redirected back to http and view the login session. Pressing F5 refreshed the screen into an active session....but I can't alter the web portal application. So I guess I'm back to square one trying to figure out why the iRule cookie persistence appears to work and source IP persistence profile doesn't. Considering what we paid for these things, I'm surprised this is that difficult to make it work....though I'm not a fan of the application we're stuck working with either...it's definitely half of the problem.