Cookie Persistence iRule help

It appears that the backend servers handle the decryption of the data stream and therefore no cookie insert will work. The issue is that if you are just passing through SSL and not having the BIGIP handle decryption you will not be able to insert a cookie or use anything other than source addr because you can't insert anything into encrypted headers. The answer we need is whether or not the BIGIP is handling SSL decryption or not. At that point we can determine if the aforementioned rule can help or not.

Hey guys,

 

 

The way we are set up is that web servers talk to the Big-IP during a HTTPS session using HTTPS. The Big-IP's have the certs and keys loaded, including the pass phrase. The clients don't talk to the web servers directly, but go through the Big-IP. I'm assuming that the web server establishes a HTTPS session with the Big-IP, then the Big-IP rewrites the session and presents it to the client. At least that was our intention to keep our HTTPS sessions encrypted when talking to the Big-IP's so that plain text transactions could not be captured.

 

 

Let me know if that answers your question.

 

 

Thanks for your help,

 

Gus

Aaron,

When I try and create the iRule you posted, I get the following error message:

01070151:3: Rule [CXT-Cookie-Insert-iRule] error:

line 128: [undefined procedure: LB::status] [LB::status pool $poolName member $nodeIp $nodePort]

The line it references is:

  Verify target server exists as a pool member and is available to accept traffic
         if { [LB::status pool $poolName member $nodeIp $nodePort] eq "up" }{
             set the pool to the value from the cookie
            pool $poolName member $nodeIp $nodePort
            if {$::debug}{ log local0. "setting pool to: pool $poolName member $nodeIp $nodePort" }

Let me know where I n00bed it up.

Thanks for your help,

Gus

What David is saying is that if your HTTPS virtual server points to a pool that has pool members using 443 as well, without any client and/or server side ssl profiles enabled, then cookie insert will never work regardless of whether "match across" is a factor or not. If that is the case, then BIG-IP is not doing any decryption and is passing SSL all the way to the webservers. It cannot insert any cookie into that stream.

 

 

For any sort of cookie persistence to work with HTTPS traffic, you must be using a clientssl profile on your HTTPS vip and have it point to a pool using port 80, or you must also use a serverssl profile to re-encrypt and send to the pool on 443. That's the only way that BIG-IP can do anything with cookies on an HTTPS stream; it has to be decrypting the SSL using a clientssl profile (re-encrypting on the back end is optional but it sounds like that's what you want so you also need a serverssl profile).

 

 

Denny

EDIT: and I have not had issues with "match across" in a regular LTM environment using cookies, as long as it is set up as I described. That CR seems to only reference ASM?

 

 

Denny

Hi Denny,

 

 

Yes, we are using client and server SSL profiles for each HTTPS VIP.

 

Hope this helps,

 

 

Thanks,

 

Gus

Hi Denny,

 

 

Let me clear it with our management, and see if we can upgrade the F5's.

 

I'll have to create a change control form and provide a back out process.

 

Currently we have 14 production ecomm sites running on the units, so doing an upgrade is risky. I'll let you know tomorrow if upgrading is even a possibility.

 

 

Thanks for your help,

 

Gus

Posted By dennypayne on 10/29/2007 2:57 PM

 

 

EDIT: and I have not had issues with "match across" in a regular LTM environment using cookies, as long as it is set up as I described. That CR seems to only reference ASM?

 

 

Denny

 

 

 

I had a case open on this with two or three CR's associated with it. I guess I got the wrong one for "match across" functionality for LTM only. In 9.4.0, I believe the GUI still showed the options for Match Across for cookie insert support, but they didn't work. In 9.4.2, the options have been removed altogether.

 

 

Searching through my old notes, I couldn't find the case number for "match across" functionality for LTM cookie insert persistence. Anyone happen to know it?

 

 

Gus,

 

 

The example rule I added can be modified to support server-side SSL. You'd need to add a server SSL profile to the virtual server and disable port translation. Then the logic would be to disable server SSL (using 'SSL::disable serverside' in the CLIENT_ACCEPTED event) for requests made to HTTP ports. I can try updating the rule at some point this week to do this.

 

 

Also, if upgrading to 9.3 isn't an option for you at the moment, it looks like LB::status was added to 9.1.x in BIGIP-9.1.2 Hotfix4 per the wiki (Click here). Of course, upgrading to 9.3 would be a much better option as it includes more fixes than HF4 for 9.1.2.

 

 

Aaron

Hey Guys,

Just a quick update, we have upgraded the F5’s to version 9.4.1. I was able to create the iRule as listed above, and will begin testing it shortly. Here are a few things we’ve done and tested since the upgrade:

Created a pool on port 80

Created a pool on port 443

Created a VIP on port 80 with its respective pool attached.

Created a VIP on port 443 with its respective pool attached.

Created a SSL client and server profile and attached them to the 443 VIP.

Set the pools to Least Connections (node)

Set the VIP’s to Cookie Insert

We ran minimal tests with 10 users, and everything seemed to work. I noticed that the F5 would insert 2 cookies, one for HTTP and one for HTTPS. I understand that Cookie Insert uses the pool name.

We then loaded the testing site with 200 concurrent sessions (connections) and persistence began to break. Once we saw that, we tried a new configuration:

Created a single pool on port 0

Created a VIP on port 80 with the single pool attached.

Created a VIP on port 443 with the single pool attached.

Created a SSL client and server profile and attached them to the 443 VIP.

Set the pool to Least Connections (node)

Set the VIP’s to Cookie Insert

We ran minimal tests with 10 users, and everything seemed to work. I noticed that the F5 would insert 3 cookies, one for HTTP, HTTPS, and one named GTSessionID.

When we loaded the testing site with 200 concurrent sessions (connections), persistence began to break just as it did with 2 pools.

Now we’re testing the iRule that was posted. Let me know if I am following the correct procedure to use this iRule.

Created a single pool on port 0

Created a VIP on port 80 with the single pool attached.

Created a VIP on port 443 with the single pool attached.

Created a SSL client and server profile and attached them to the 443 VIP.

Set the pool to Least Connections (node)

Created a Universal Persistence Profile and attached the iRule to it.

Set the VIP’s to use the Universal Profile.

When I do that, I get the following error message:

01070394:3: SSL::disable in rule (gus_test) requires an associated SERVERSSL or CLIENTSSL profile on the virtual server (ST_http_173-lbc.aw.amo.com)

Am I supposed to set the server and client SSL profile on the HTTP (80) pool as well?

Am I just to create a single VIP servicing port 0?

Thanks for your help,

Gus

Hi Gus --

You could create a single port 0 VS, but you'd get the same error.

Leave the clientssl profiles configured as they should be, and replace this:

      if { [PROFILE::exists clientssl] == 1} {
         if {$::debug}{log local0. "Client SSL profile enabled on VIP.  Disabling SSL"}
         SSL::disable clientside
      } 

With this little trick to wrap the offending call:

      if { [PROFILE::exists clientssl] == 1 } {
         if {$::debug}{log local0. "Client SSL profile enabled on VIP.  Disabling SSL"}
            set ssl_disable "SSL::disable clientside"
            [eval $ssl_disable]
         } 
      }

It effectively hides the offending command from the parser police & executes it only when appropriate.

HTH

/deb