Forum Discussion
David_L_
Nimbostratus
NimbostratusSSL-Termination Persistence
I need to enable persistence for an SSL-terminated connection on a version 9.4.1 LTM.
The Configuration Guide and these forums indicate that SSL Persistence is not supported for SSL-terminated connections.
The Config guide indicates that:
To do this, you write an iRule using the HTTP::header command and then assign the iRule to the virtual server. Whenever the BIG-IP terminates an SSL request, the iRule inserts the certificate status as a header into the request, and persists the session based on that status. "
Unfortunately no examples are given, and I'm concerned about whether this method would persist connections after IE's periodic renegotiations.
I've thought about using a cookie hash on the existing JSESSIONID cookie generated by the application, but I can't see exactly how to do this - nor can I tell if the SSL termination would impact this.
Can anyone tell me the best way to manage persistence for SSL terminated connections? (Preferably with an example!)
Thank you very much.
David L.
David_L_OK - To update this in case anyone is listening - I've copied/written/modified a rule that meets this requirement. There's one part I can't get to work correctly though - any thoughts would be appreciated.
The part that doesn't work is the "persist delete" statement. The goal is to delete the persistence record if the user logs out. The "if" statement is being evaluated properly, but the "persist delete" statement does not seem to be doing anything. The record remains until its 1800 second timeout.
when CLIENT_ACCEPTED {
set add_persist 1
}
when HTTP_RESPONSE {
if { [HTTP::cookie exists "JSESSIONID"] and $add_persist } {
persist add uie [HTTP::cookie "JSESSIONID"] 1800
set add_persist 0
}
}
when HTTP_REQUEST {
if { [HTTP::cookie exists "JSESSIONID"] } {
if { [HTTP::uri] ends_with "logout.do"} {
persist delete uie [HTTP::cookie "JSESSIONID"]}
else {
persist uie [HTTP::cookie "JSESSIONID"] 1800
}
}
}- Once SSL is terminated at the BIG-IP the connection can pretty much be handled like any other non-encrypted connection, meaning the way you do persistence is completely up to you.
If your application calls for JSESSIONID persistence, you can certainly do that. If you want something simpler like source persistence or persistence based off of some information coming through in the initial request, that can be done as well.
The first step is for you to decide what your application requires as far as persistence. Once you know what is needed and can lay it out for us (E.G. "I need to do x, y and z while watching out for ..."), I'm sure you'll be able to get a good starting point here in the forums.
HTH,
Colin
