Forum Discussion
scarpozzi_82104
Nimbostratus
NimbostratusF5 LTM Sticky Sessions between 80/443
I'm new to F5. We bought 2 1600s, but couldn't afford training so I'm winging it. I used to use another load balancer product and am having to figure this out as I go. I need some major help with what may be a simple problem.
I've got 3 portal servers that have authentication pages on them. The portal is poorly written and does a number of redirects through the login process. You start on port 80...go to 443 for the login page...then get redirected back to 80 after a successful login. I created 2 virtual servers that point at 80 & 443 and set cookie persistance on each.
The problem is, since they're separate virtual servers a client can pull server1 on the first 80 request, server2 for the 443 auth, and server3 after they successfully login. It results in the cookie stating that the user has authenticated, but the final server's session data doesn't match the one they posted their credentials with.
What I want is a way to stick all 80/443 connection to that virtual hostname to one physical server per cleint connection...thus keeping everything working and being as transparent to both the end user/server as possible. Not sure if this would be an iRule or creating a new persistance profile. I've never done either, so I don't know where to start. Any help would be most appreciated.
Thanks.
hoolioCirrostratus
Hi Scarpozzi,
Welcome. I hope you enjoy working with the F5 kit.
If it's the same pool of HTTP servers for both the HTTP and HTTPS virtual server, you can use the same cookie insert persistence profile on both virtual servers. That should work to ensure clients are persisted to the same server regardless of whether the request was to the HTTP or HTTPS virtual server.
If that doesn't work for you, can you clarify what ports the pool members are defined on?
Thanks, Aaron
scarpozzi_82104Both Virtual servers are using the same out of the box 'cookie' persistance.
I can't use the same pool unless it's possible for the 'common' pool to answer both 80 and 443 requests.
The hard coded redirects in the portal authentication pages are what initiates the changes between ports 80 and 443. So if the pool only answers on port 80, the authentication page will never load for the portal...
For example, my current configuration has 2 pools.
http_pool has members 192.168.100.x:80
https_pool has members 192.168.100.x:443
Thank you for the reply...I really appreciate any help...I've got to get this working this week....somehow.- hoolioThat makes sense. The simplest option then if the pool members are on the same IP address but different ports would be to use a single custom source address persistence profile with match across services enabled on both virtual servers.
SOL5837: Match Across options for session persistence
http://support.f5.com/kb/en-us/solutions/public/5000/800/sol5837.html
Aaron - scarpozzi_82104That sounds like what I need. I checked the options in source address affinity and it looks like the match pools option will do it.
It's really difficult to do load testing on the system though because now all requests from my client are going all to the same host. It took us using 3 different systems before we could even prove that the sessions were being load balanced....because that's how good the source address affinity was working.
Thank you for the reply. I have a lot to learn about this box and how to configure it. - scarpozzi_82104I think I spoke too soon. I'm still seeing issues. The source address affinity appeared to be helping, but then looking at results in jmeter showed differently until the portal no longer accepted logins. I switched back to the original cookie profile and it started working again, but throwing errors occasionally.
In reading through the documentation, I gathered that source/destination affinity is the only way to balance across pools when needing connections between virtual servers 80:443. I think what I might be needing is to add the cookie persistance on top of that...maybe through an iRule...unless there's another way. I'm also kind of thrown off because of the whole oneconnect stuff. I'm not sure which of these options is the right combination to get it working.
EDIT: Looks like rather than doing it across the pools, I needed to set it across virtual servers. Working now. - hoolioGlad you got it working. If you did want to use "cookie insert"-like persistence you could use an iRule from Kirk Bauer:
Cookie_ Encryption_across_pools_and_services
http://devcentral.f5.com/wiki/default.aspx/iRules/Cookie_Encryption_across_pools_and_services.html
Aaron