Forum Discussion

hc_andy_35682's avatar
hc_andy_35682
Icon for Nimbostratus rankNimbostratus
Feb 01, 2012

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

Hi All,

 

 

I'm trying to determine the best way to handy persistence for HTTPS connections based on our security mode below.

 

 

We have a security model where we have a F5 in the Public Zone and another F5 in the Private Zone.

 

 

Client --> Pub_F5 ---reverse proxy / Port 80--> Priv_F5 -> Real_Servers

 

 

- Clients will make a HTTPS connection to the VIP on the F5 in the Public Zone which is listening on Port 443.

 

 

- The connection is then reverse proxied to a VIP on the F5 in the Private Zone listening on Port 80. So communication between Public and Private Zone is clear text and no longer encrypted.

 

 

- The VIP on the F5 in the Private Zone will then load balance the connection to the backend real servers.

 

 

Based on this security model, how do we ensure that clients are persisted to the same backend real server in the Private Zone??? What persistence profile should be applied to either F5 in each security zone to make this work???

 

 

Thanks you in advance.

 

 

Andy

 

8 Replies

  • 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