For more information regarding the security incident at F5, the actions we are taking to address it, and our ongoing efforts to protect our customers, click here.

Forum Discussion

abvaidya_182376's avatar
abvaidya_182376
Icon for Nimbostratus rankNimbostratus
Jan 12, 2015

http and https session persistence based on a header value and client ip combination

I am trying to configure BIG IP SLB for session persistence based on value of a non standard HTTP header (lets say "XYZ") and facing a few

 

hitches on my BIG IP site. I want that all client HTTP / HTTPS requests with same value of header "XYZ" should go to the same server behind

 

SLB, always. The issue is mainly due to incorrect combination of “HTTP Profile” and “Persistence profile” due to which request on HTTPS from

 

client is not reaching the servers via SLB. It seems to a persistence profile issue because when I remove the Http profile (just created a

 

random HTTP profile) and the persistence profile (which is based on irule), the same server becomes reachable via SLB.

 

The irule is

 

when HTTP_REQUEST { if {[HTTP::header exists "FROM-AGENT-ID"]} { persist uie [HTTP::header values "XYZ"] } }

 

My end aim to have persistence based on combination of value of header as well as IP address of the client connecting. In case persistence

 

based on combination is not possible, persistence based on just header should be fine. I need to support both session persistence on HTTP as

 

well as HTTPS (of course by two different virtual servers)

 

The screenshots show the relevant configuration of the SLB. If you can pin point the configuration causing the issue, it would be of great help.

 

 

19 Replies

Show More
  • Brad_Parker's avatar
    Brad_Parker
    Icon for Cirrus rankCirrus
    Jan 12, 2015

    First of all, you can not attach an HTTP profile to an HTTPS VIP without a client SSL profile. If you want to use Universal persistence using a combination of the clientIP and a header value your iRule will need to set a value based on the two; i.e. persist uie "[HTTP::header values "XYZ"][IP::client_addr]". Lastly you will want to check that box in your persistence profile, "Match Across Virtual Servers"

     

  • Brad_Parker's avatar
    Brad_Parker
    Icon for Cirrus rankCirrus
    Jan 12, 2015
    Rather than screenshots, post you config in the future. It will be easy to read.
  • abvaidya_182376's avatar
    abvaidya_182376
    Icon for Nimbostratus rankNimbostratus
    Jan 13, 2015

    Hi Brad, i searched little more about this and found the below link which says that in case you want to have irule based persistence profile, for HTTPS, you need to have a client SSL profile which will decrypt the request and after persistence by persistence profile, a SSL server profile is required to re encrypt the request before sending to the server. 

          https://devcentral.f5.com/questions/error-http_request-event-in-rule-requires-an-associated-http-fasthttp-profile-on-the-virtual-server

    A few questions

    1) Is there any specific that is required in the client SSL and server SSL profiles for this to work? Like, is any property value required to be same in the two profiles?

    2) I don't know much about Universal persistence as referred by you in your last reply. I just happened to use it. Is there any reason that i should use only this persistence? My used case is simply what i explained in my initial questions

    Regards Abhishek

    • Brad_Parker's avatar
      Brad_Parker
      Icon for Cirrus rankCirrus
      Jan 13, 2015
      You only need a server SSL profile if you want SSL to the backend server. You can just use the default server SSL profile unless you know you need to use any of the other parameters. There is no matching property to set between the two SSL profiles in this case as you are not using proxy mode. In my experience universal persistence is used in special cases like the one you defined(wanting to persist based on a combination of a header value and client IP). Many times source address persistence works well and doesn't require you to SSL offload and can also persist across Pools, Virtual Servers, and services as well. Cookie based persistence also has a lot of perks and that's what we use, but it requires at a minimum the client SSL profile as well. Cookie persistence writes a cookie in the clients browser that is a hash of the backend node's IP. This can also work across pools and virtual servers provided the same nodes are available and you use the same cookie name. I hope this helps a bit. https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm_configuration_guide_10_0_0/ltm_persist_profiles.html