Handling Persistence for HTTPS connections in a two tier security model??

Hi Andy,

You could use standard cookie insert persistence on the internal LTM and then use an iRule on the external LTM which piggybacks on that persistence cookie. You should just need to update the cookie name in this iRule. Make sure to use a OneConnect profile on both the external and internal LTM virtuals to ensure each request is persisted as expected.

when HTTP_REQUEST {

 Persist based on the internal LTM persistence cookie value
if {[HTTP::cookie my_persist_cookie] ne ""}{
persist uie [HTTP::cookie my_persist_cookie] 3600
}
}
when HTTP_RESPONSE {
 If the internal LTM persistence cookie is set in the response
 add a persistence record for this LTM
if {[HTTP::cookie my_persist_cookie] ne ""}{
persist add uie [HTTP::cookie my_persist_cookie] 3600
}
}

Aaron

Thanks for the response Hoolio and you're always as helpful as ever!

 

 

Can you please explain how the client's browser will then receive a cookie from the external LTM given that the cookie persistence is applied on the internal LTM.

 

 

Does the OneConnect profile allow the cookie to be passed from the internal LTM to the external LTM and then to the client's browser???

I'm assuming the reverse proxy will pass the request and response through fairly transparently and include the LTM internal VS's persistence cookie. If that's true, then you can use that as a unique key to persist the client on the LTM external VS. Here's a bad ascii diagram and description.

Request 1
client(1) ->VS on LTM external(2) ->Reverse Proxy(3) ->VS on LTM internal(4) ->server

Response 1
client<- (8)VS on LTM external<- (7)Reverse Proxy<- (6)VS on LTM internal<- (5)server

Request 2
client(9) ->VS on LTM external(10) ->Reverse Proxy(11) ->VS on LTM internal(12) ->server

1 - 5: client makes a new request with no persistence and server responds

6: LTM internal sets a persistence cookie for the LTM internal VS default pool member

7: LTM external iRule adds a persistence record in memory mapping the persistence cookie value from LTM internal to the LTM external VS default pool member

8: Client receives LTM internal VS cookie

9-10: Client makes new request to LTM external VS with LTM internal VS cookie. iRule persists on that cookie value to same LTM external VS default pool member

11-12: LTM internal VS persists on persistence cookie value to same LTM internal VS default pool member.

OneConnect is necessary to ensure each HTTP request is evaluated for persistence instead of once per client to TCP connection. See this article for more info:

sol7964: Persistence may fail for subsequent requests on Keep-Alive connections

http://support.f5.com/kb/en-us/solutions/public/7000/900/sol7964.html

By default, the BIG-IP performs load balancing for each TCP connection, rather than for each HTTP request. Once the initial TCP connection is load balanced, all HTTP requests seen on the same connection are sent to the same pool member. You can modify this behavior by forcing the server-side connection to detach after each HTTP request, which in turn allows a new load balancing decision according to changing persistence information in the HTTP request. You can force the server-side detachment by applying a OneConnect profile to the virtual server, or by using an iRule to explicitly detach the server-side connection after each HTTP request.

and/or this one from Deb:

OneConnect

http://devcentral.f5.com/wiki/AdvDesignConfig.OneConnect.ashx

Note that it's a lot more efficient to use OneConnect to force persistence evaluation on each HTTP request compared with using LB::detach which basically prevents serverside keepalives.

Aaron

Actually I guess I should have clarified first. Do you need persistence on the reverse proxy pool and the application pool? If so, the above suggestion should work.

 

 

If you only need persistence at the app pool level, you can just use cookie insert persistence with OneConnect. You wouldn't need the iRule on the external VS.

 

 

Aaron

Hi Aaron,

 

 

Cheers for the detailed step-by-step explaination.

 

 

Given that we just need persistence at the app pool level, do I just do the following:

 

 

- set cookie insert persistence with OneConnect on the Internal LTM.

 

- set OneConnect on the External LTM (do I need cookie insert persistence here too???)

 

- irules no longer required.

 

 

 

Thanks.

 

 

Andy

If you only need persistence at the app server layer you should use cookie insert persistence with OneConnect on the internal LTM VS. You don't *need* OneConnect on the external LTM VS, but it would still help that LTM and the reverse proxies in lowering the connection count. If you're using SNAT on either VS you want to use OneConnect on, you can use the default OneConnect profile with a /0 source mask. Else, if you're not doing source address translation create a custom OneConnect profile with a /32 source mask.

 

 

Aaron

Thanks Arron.

 

 

Sorry to bother you, but I have one last queston which is still a little hazy in my head and that is how the client's browser receives the cookie given that cookie persistence is only applied on the internal LTM and not the external LTM.

 

 

http://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_implementation/sol_http_lb_cookie.html

 

"Cookie persistence directs session requests to the same server based on HTTP cookies that the BIG-IP system stores in the clients browser."

 

 

I've looked over your ascii art work many times and read the doco above but I still don't understand how the cookie gets stored on the Client's browser. Is the cookie just passed back along the chain from internal ltm -> external ltm -> client browser. Is this just how it works? How does the external LTM know that it needs to send a cookie to the client's browser when it doesn't have cookie persistence enabled?

 

 

Thank you.

 

 

Andy

 

 

No bother. The external LTM will not use or modify the persistence cookie that the internal LTM sets. Similarly, I expect the reverse proxy/ies will not modify the cookie. So it should "just work".

 

 

Aaron