Forum Discussion
RACQ_74493
Cirrus
CirrusiRule to enable persistence for terminated SSL sessions
Hello,
Ok so we have a new Application (lets call it Dog)and there are 6 servers (DogBoxes) in a single pool and the software suppliers tell me that the client would function optimally if it always returns to the App Server it initiated with, as information is cached there even though. So transport is SSL, no worries a SSL Persistence thingy. Nope won't work for SSL Terminated sessions. OK I need to write an iRule, something I have done previously by coping one that I stole from here and modified clumsily to work as my own. Which means I have no ability to code or real understanding of iRule thingies.
Can someone point me in the right direction to try and handle correctly persistence for terminated SSL sessions?
My discovery so far leads me to believe that there is a setting for this, and I need to use the HTTP::header command and the persist:ssl and that is as far as I can go.
I have done a search and read 20 or more articles but I am none the wiser.
Thanks
David.
6 Replies
hoolioCirrostratus
Hi RACQ,
There is no need for an iRule. If you're terminating the SSL you can use cookie insert persistence without an iRule. Start by testing with the default cookie insert persistence profile. If you want to customize the timeout or cookie name, you can create a custom cookie insert persistence profile and add that to the VS.
Aaron
RACQ_74493Thanks Aaron,
So even though we decrypt and then reencrypt on to the App Servers, the f5 will match the Session ID of the client with the correct session on the right App server?
I am just concerned when for when we start to run load tests that the results will be skewed across the servers in the pool.
Thanks
David.- hoolioHi David,
With cookie insert persistence, LTM will insert a cookie whenever a load balancing decision is made. The cookie name and value contain the pool name and member IP:port. By default the cookie is set as a session cookie (no expire time) so the client should present it on requests for as long as the browser is open. Each time LTM parses a request with a persistence cookie, it will persist the client to the same pool member, assuming the member is available.
This is independent of the SSL session ID. Incidentally, I think most versions of IE can change the SSL session ID every two minutes. So that's not always a dependable persistence method.
Aaron - RACQ_74493Thanks again for the explanation.
You have been very helpful, as always.
David. 
JJay_44003Nimbostratus
What would happen if the client will not accept cookies?- hoolioIf a client doesn't send cookies, cookie persistence would fail. You could use a secondary persistence of source address to handle these clients.
Aaron
