SSL Offloading + X-Forwarding + Cookie persistence

There's actually a few things going here I think.

 

 

1. Users are getting moved around between servers because you don't have any kind of persistence enabled. The cookie-based persistence recommendation is actually a good one. Simply apply it in the virtual server properties and the client will receive a cookie that indicates the first chosen pool member.

 

 

2. Using any kind of layer 7 persistence method (cookie, universal, hash) requires the BIG-IP to be able to SEE the HTTP payload, so you would definitely need to decrypt the traffic with a client SSL profile. Whether you re-encrypt with a server SSL profile is up to you and the server admins, but generally speaking you're going to get a potentially huge performance boost if you leave it unencrypted.

 

 

3. The x-forwarded-proto header is rarely used, if ever, and I can't image Blackboard cares about it either. The x-forwarded-for header, however, is used quite often in situations where the proxy (BIG-IP) must change the client's source address (for internal routing) but the server still needs to be able to see the client's true source. You didn't indicate that you were SNATting, so I don't believe this header is necessary.

 

 

4. The HTTP profile's Redirect Rewrite setting is used when you are NOT re-encryting to a backend server, and that server (because it doesn't realize it's behind an SSL-based proxy) sends redirects to itself using "http://". The setting automatically rewrites these to "https://". If you're re-encrypting to the server, then this setting has no purpose.

 

 

 

Also, can you elaborate on "TOO_MANY_REDIRECTS"?