ssl timeouts

[donaghq_2]

Hello. I am having a problem with timeouts when using ssl load balancing. The ssl termination point is on the webserver. I am hitting the VIP on port 443 and then balancing between 2 servers at the backend. The problem is that the users' sessions are timing out at random intervals. When one of the servers is powered down this issue does not happen. Could this be something to do with the content switch and flow timeouts?? I have added the line "sticky-inact-timeout 45" thinking that it might be that but it has not made a difference.

My config is as follows

********************************

service ugwprd01-ssl-2443

ip address 10.48.7.3

protocol tcp

port 2443

keepalive type ssl

redundant-index 210

active

service ugwprd02-ssl-2443

ip address 10.48.7.6

protocol tcp

port 2443

keepalive type ssl

redundant-index 220

active

***************************

owner x

content x

vip address 10.48.1.6

port 443

protocol tcp

application ssl

add service ugwprd01-ssl-2443

add service ugwprd02-ssl-2443

redundant-index 1210

advanced-balance ssl

sticky-inact-timeout 45

active

*************************************

THANKS!

[pknoops · Accepted solution]

You may be running into an IE issue whereby the SSL session id is changed every 2 minutes. This becomes a problem when using advanced-balance ssl and application ssl as this is l5 stickyness based on session id. After 2 minutes, this changes. With only one server you will not see this occur as you are on the same server to begin with.

The only solution here is to use some type of SSL temrination device that we offer such as an SCA. You may also want to back off the VIP to layer 4 and not use application ssl and advanced-balance ssl and have the content rule look like this:

content x

vip address 10.48.1.6

port 443

protocol tcp

add service ugwprd01-ssl-2443

add service ugwprd02-ssl-2443

redundant-index 1210

active

See if changing to L4 makes things work better.

Regards

Pete Knoops

Cisco Systems

[donaghq_2]

I have tried that and the users appear to be happy so thank you. I have had to put in stickiness based on source IP in order to get it to work. Will stickiness work on source IP even if I am natting a public IP to a private one? Am I compromising security by not balancing on SSL?

[pknoops]

Glad to hear things are better. Source IP sticky will work fine in a NATing senario as long as it is not a many to one nat. If each user has his/her own ip address after being NAT'd, it should be fine.

Pete..

[donaghq_2]

it is a many to one NAT! any ideas on what I should do now?

[donaghq_2]

it is a many to one NAT! any ideas on what I should do now?

[pknoops]

Hmm, that's a tough one. Cookies is not an option because it is SSL traffic and will be encrypted.

You may be at a point where you need to have some type of SSL termination device prior to getting load balanced like using an SCA or an SSL module on the CSS itself.

In general, because of the IE timeout issue, your ONLY option is Sticky Source IP. With the NATing involved now, I believe you need to turn to another hardware solution from an SSL termination perspective working in conjunction with the CSS

Pete..

[donaghq_2]

as it turns out the application people were not happy with the L4 service. They maintain that when they switched one of the webservers off they got "page cannot be displayed" which is fine. They say that upon the fourth refresh they got back the page that they were previously in back i.e they were not forced to logon again. This seems to strange to me and defeats the purpose of ssl. Would there be any logical explanation for this. The same SSL cert resides on the two webservers. Maybe this is the reason for the seamless changeover?!

The business have subseqently decided to go with "advance-balance ssl" with one webserver as this has been extensively tested. There will have to be manual changeover in case of failure which is not ideal. In any case I will have to find a satisfactory resolution to this, albeit L4 or L5 balancing!

[pknoops]

By the way, in my opinion, you are not compromising security simply because the packets are still ssl all the way to the server. The encryption is fine

Pete..

[ct_yau]

According to this document: http://www.cisco.com/en/US/products/hw/contnetw/ps789/products_configuration_example09186a0080094068.shtml , "SSL ID renegotiation problem" is with IE 5.0.

Are you talking about the same problem? Are other IE versions affected too?

CT Yau

Hong Kong