HTTPS persistence SSL session, ACN 4.2.1

brian.willingham · ‎02-26-2003

Customer is experiencing a problem resulting in the ACN software resolving the host.domain.com twice. Webapplication https://host.domain.com/webapp/index.jsp. The customer uses a ACN to proxy the https request. The host.domain gets resolve to 1 of 4 available application servers (webserver). At the application login page (index.jsp) the user is successfully authenticated by the application's Login servlet on webserver 1. The user is then redirected to the select application, local to the webserver 1. It appears that when the ACN receives the response from webserver 1 with the fully qualitfying URL. The redirection cause the ACN to resolve the host.domain against DNS and as a result, the user's browser is redirected to a different webserver. The users previous session is no longer valid, breaking the client/webserver trusted relationship

If the above user uses 1 of the 4 available IP address on the DNS entry, the users successfully maintains the SSL session. The customer is migrating to a Cisco Content Engine 560 running version 4.2.1 ACN software.

I understand there are ACN features that could effect the HTTP session persistence/SSL trust. The services/features include boomerang, Reverse Proxy, content balancing. I request information on the service or feature of the ACN that could cause the problem I speak of from above.

I understand there are different methods of implementing session persistence, like sticky session and SSL sticky, but believe the ACN does provide this feature.

Gilles Dufour · ‎02-27-2003

The methods you mentioned are for loadbalancing device like the CSS or the CSM. The Cache Engine is not a loadbalancing device and therefore there is no way to do what you asked.

You should use a CSS or CSM to do loadbalancing and not use DNS which is not intended to be used for this purpose.

Gilles.

brian.willingham · ‎02-27-2003

Thanks for your reply, but I’m afraid that you don't understand my problem. My explanation is sort of vague. I will attempt to outline the problem.

Our customer sits behind a Cisco Content Engine. One of the features they use is proxy. All of the application users must be authenticated before any requests are proxied. This feature is not believed to be a concern.

I’m not quite clear, but I believe another one of the CE’s features/services is causing the user’s browser to access the application from one of the other webservers listed in DNS for the application host.domain combination. This prevents the browser from loading the application, because the login data built at user login and stored within the session object belongs to the initial webserver at user login, not on the second webserver.

By redirecting the user to another one of the webserver, the CE does not appear to be keeping session tied to the initial webserver. The CE must be able to keep the session persistent by redirecting the users to the same webserver the session was build on.

The webservers listed in DNS is not really used for load balancing. If the customer bypasses the CE device or uses one of the four available IP addresses entries in DNS, the user is successful in accessing the application after initial login.

Thanks again.

Gilles Dufour · ‎02-27-2003

Brian,

apparently I misunderstood the question.

However, the new explanation is not clear on the traffic flow.

What I understand is that the client will open a connection to the CE (proxy)

for host.domain.com (that can be resolved in 4 different ip addresses).

The CE does the client authentication and then it should server the content to the client but it does not because it goes to the wrong server.

All this is not very clear. Could you capture a sniffer trace on CE side and client side to understand what exactly is going on in terms of TCP/IP traffic.

Thanks,

Gilles.

brian.willingham · ‎03-12-2003

The customer is experiencing network issues when attempting to access our application. The customer is experiencing has been seen with a previous customers that had a similar network devices.

The customer uses a Cisco Content Engine CE-560 with Application and Content Networking Software (ACNS) version 4.2.1. The problem seems to a result of the ACNS resolving the hostname.domain.com twice. The webserver's DNS (hostname.domain.com) entry resolves to one of four available webservers (DNS round robining).

nslookup hostname.domain.com

webserver1 webserver2 webserver3 webserver4

nslookup hostname.domain.com

webserver2 webserver3 webserver4 webserver1

and so on.

All client/webserver communication is through SSL. When the customer uses the FQDN URL (https://hostname.domain.com/webapp/index.jsp) to access the application login page, the server portion of the URL is resolved to webserver1. At this time, the customer has an established HTTPS session with webserver1. Once a login servlet running on webserver1, receives the customer supplied login credentials, the servlet sends a server response 302 redirecting the customer to the selected application.

This redirection response seems to cause the ACNS to resolve the hostname.domain.com and as a result, the customer's browser is redirected to a different webserver, webserver2. The users previous session is no longer valid, causing the application to generate a false inactivity timeout.

If the customer sends a HTTPS request using anyone of the four IP address from DNS, the session is maintained and the customer does not receive the false inactivity timeout, because the session is not "broken".

The customer is migrating off of a Netscape (iPlanet) Web Proxy solution and does not experience the problem accessing the application, using the FQDN URL.

DNS caching is enabled on the customer CE.