Forum Discussion

pjcampbell_7243's avatar
pjcampbell_7243
Icon for Cirrus rankCirrus
Feb 25, 2009

Cookie encryption issues?

We have a BIG-IP 9.4.3 Build 1.4 Final and I am trying to encrypt cookies using the http-enc-cookie http profile.

 

 

Under my virtual server Resources, I have specified a custom Default Persistence Profile, which in term uses the parent "cookie", to simply set a custom cookie name, that we'll call BIPcookiemonster.

 

 

BIPcookiemonster is then listed under "Encrypt Cookies " on the http-enc-cookie http profile.

 

 

My virtual server also has http-enc-cookie selected.

 

 

When I go to view the website, it appears that the cookie is being encrypted:

 

127.0.0.1 cookie: BIPcookiemonster=DusutP4AZblYGVAePa8GVRhB2dY8WK4Ii/CVoq1wRGjEpB44sR7UHVbrWM5NJ9BDGPw2OOAzPWANXvQ= Allow? (Y/N/Always/neVer)

 

 

However, every single time I am being directed to the same server. I have the load balancing method setup as Round Robin.

 

 

Any advice for this situation?

 

 

It seems to me that the "fallback persistence method" is being utilized. It is set as source_addr. If I turn that off, I can see myself getting different pool members. Why is it not using the default method?
config
design

3 Replies

Sort By
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Feb 25, 2009
    If you disable source address persistence and test, do you get persisted correctly back to the same pool member? If you manually delete the cookie or close all your browser instances, do you get load balanced again? You will need to either delete the source address persistence record or wait for it to time out.

     

     

    Also, it would be good to upgrade to the latest 9.4.x version (currently 9.4.6) to get a lot of stability fixes introduced since 9.4.3.

     

     

    Aaron
  • pjcampbell_7243's avatar
    pjcampbell_7243
    Icon for Cirrus rankCirrus
    Feb 25, 2009
    If I disable the source_addr fallback persistence, I do seem to get the same pool member within the same session. And different pool members across different browsers originating from the same source address. Where as when I turn source_addr fallback on, I get the same pool member across all browsers.

     

    Why would it use the fallback profile? I thought it is only supposed to use the fallback ONLY if the default does not function?

     

     

    EDIT: I think I have a bit more testing to do actually. The production method of encryption is different than that of test. Test is using an iRule:

     

     

    when RULE_INIT {

     

    set ::key [AES::key 128]

     

    }

     

    when HTTP_RESPONSE {

     

    set decrypted [HTTP::cookie "BIPxxxx-http"]

     

    HTTP::cookie remove "BIPxxxx-http"

     

    set encrypted [b64encode [AES::encrypt $::key $decrypted]]

     

    HTTP::cookie insert name "BIPxxxx-http" value $encrypted

     

    }

     

    when HTTP_REQUEST {

     

    set encrypted [HTTP::cookie "BIPxxxx-http"]

     

    HTTP::cookie remove "BIPxxxx-http"

     

    set decrypted [AES::decrypt $::key [b64decode $encrypted]]

     

    HTTP::cookie insert name "BIPxxxx-http" value $decrypted

     

    }

     

     

    where my test setup is using http-cook-enc http profile. With production, when I turn off the fall-back source_addr persistence, there seems to be NO persistence.
  • pjcampbell_7243's avatar
    pjcampbell_7243
    Icon for Cirrus rankCirrus
    Feb 25, 2009
    I made my test server mirror production in terms of cookie config, and was able to duplicate that persistence did NOT work when source_addr turned off, THEN, I changed the iRule to the example seen here: http://devcentral.f5.com/weblogs/Joe/archive/2005/11/09/1541.aspx and that seemed to fix it? Still testing...