Forum Discussion
pjcampbell_7243
Cirrus
CirrusCookie 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?
hoolioCirrostratus
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_7243If 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_7243I 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...