CSS11501S - HTTP and SSL don't stick together

[t.graham]

We have a problem that SSL and HTTP streams from the same session seem to be processed as different conversations. The web application generates a unique session key that appears in the URL of both HTTP and HTTPS requests. This key is 52 char long and appears after the string "usersessionid=" in the URL.

What should happen is that cleartext port 80 requests to 10.3.2.10 show up on "http-rule" and get balanced using the 'advanced-balance' facility based on the session id appearing in the URL after the string "usersessionid=".

Similarly SSL sessions on 10.3.2.10/443 are decrypted by the SSLM and forwarded to port 80 of the VIP (10.3.2.10) and processed in the same way.

The problem is that the cleartext streams coming from the SSLM and the client seem to be processed as separate conversations. I want to have them stuck together.

For example:I have a browser open with an HTTPS session active. I modify the URL to say HTTP instead of HTTPS and leave the "usersessionid" alone. I then get bounced to the other app server - I wanted to get stuck to the same server I was on; based on the in-URL "cookie" of the usersessionid field. (The config says look for the string "usersessionid=" and take the next 52 characters as the cookie. The "no found cookie" parm proves to me that the parsing is working by not dumping me off to a sorry server.)

We have doublechecked and the usersessionid doesn't change but for some reason the CSS decides this is a different conversation and bounces to another server.

As long as the protocol (HTTP, HTTPS) does not change, the stickiness seems fine. This should be a simple configuration and the Cisco docn clearly says this will work. What am I missing or is there a bug?

!*********************** SSL PROXY LIST ***********************

ssl-proxy-list sslweb

ssl-server 10

ssl-server 10 rsacert cert-key

ssl-server 10 rsakey rsa-key

ssl-server 10 vip address 10.3.2.10

ssl-server 10 cipher rsa-with-rc4-128-md5 10.3.2.10 80

active

!************************** SERVICE **************************

<SNIP> - web servers defined

!*************************** OWNER ***************************

owner owner1

content http-rule

vip address 10.3.2.10

add service <many web servers>

advanced-balance url

string process-length 52

string prefix "usersessionid="

protocol tcp

port 80

url "/*"

balance aca

sticky-no-cookie-found-action redirect "http://10.3.3.11"

content ssl-rule

protocol tcp

port 443

add service ssl_module

vip address 10.3.2.10

active

[Gilles Dufour]

could you try to configure :

"string operation hash-crc32"

under the content rule and see if that makes a difference.

If not, could you capture a sniffer trace of the failure on the server side and have it attached to this discussion [or send it to me gdufour@cisco.com].

Also, what version are you using ?

Thanks,

Gilles.

[t.graham]

Wow. That at least helps a lot! (Its hard to prove a negative - how do we know that it is really working? I had to hit refresh 50+ times to break it with the plaintext comparison).

Anyway this does seem to work. Why???

Thanks. I was really tearing my hair out.

BTW we are on 08.10.0.02

[t.graham]

Update! Now it seems that it takes a few clicks to get the session pinned to one server. It seems to round-robin the responses for a few links then finally stabilizes and gets pinned to one server. Once this happens the stickiness seems to work.

[Gilles Dufour]

the problem is that the CSS does not learn the cookie values.

So, the default function is to match the value to a preconfigured string entry.

You should normally configure a string for each server and the CSS will try to match the one sent by the client to one of the server string.

With the command I gave you, the CSS will hash the value and select a server based on the hash value.

As long as the cookie value stays the same, the hash will always give the same result and select the same server.

With a hash, there is no need to pre-define a cookie string for each server.

However, you could be on server1 and receive a new url with cookie=x. This could hash to server2, that will give you another cookie=y which could send you back to server1. Until you get lucky and the hash sends you back to the same server and you will stick to this server.

If you control the cookie sent by the servers, you should have them send a random value with a static value that identifies the server.

ie: cookie=server1-random_number.

You can then tell the css to extract the static value and compare it to a string you would configure for each server.

If your clients support cookies, maybe you could simply use arrowpoint-cookies.

You can turn it on with the command 'advanced-balance arrowpoint'

Regards,

Gilles.