Guest

Cisco CSS 11500 Series Content Services Switches

Configuring the CSS 11xxx Products and Web Applications to Convert a Session from HTTP to SSL and Stay Stuck

Document ID: 16202

Updated: Jan 31, 2006

   Print

Introduction

This document provides a sample configuration for the CSS 11xxx Products and Web Applications in order to keep a client stuck to the same server, whether you use HTTP or SSL.

Prerequisites

Requirements

Ensure that you meet these requirements before you attempt this configuration:

  • Understand the basics of HTTP and SSL.

  • Have knowledge about CSS 11xxx Products and Web Applications.

Components Used

The information in this document is based on these software and hardware versions:

  • Cisco WebNS Software Release 5.00 and later

  • All Cisco CSS 11xxx series Content Services Switches

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If your network is live, make sure that you understand the potential impact of any command.

Conventions

Refer to the Cisco Technical Tips Conventions for more information on document conventions.

Background Information

Many web sites have clients enter their site with the help of Hypertext Transfer Protocol (HTTP) port 80, but want the clients to transition to Secure Socket Layer (SSL) protocol during the session for secure transactions. Here is a way to keep a client stuck to the same server, whether you use HTTP or SSL.

The client requests HTTP traffic destined to the Virtual IP (VIP). The switch makes a load balance decision. In this document, traffic goes to server s1. The client is then stuck to server s1 based on one of the advance-balance methods, such as sticky-srip, sticky-srcip-dstport, and cookies. Refer to Configuring Sticky Parameters for Content Rules for more information.

During the session of the client, the transition is made to SSL port 443 when the client selects a link on the page that redirects to https. This causes a new content rule to be hit and the client may be load-balanced to another server. As the traffic is now encrypted https (SSL/TLS), the CSS is not able to check above layer 4 (the TCP port number) for cookies, URLs etc., because the requests are encrypted when the information passes the CSS. In order to prevent the occurrence of this issue, configure the redirecting HREF on each server to point back to https at the same servers public address, not the VIP address, as shown here:

<A HREF="https://servers_own_ip_address/path"> secure site </A>

If your servers are in a private address space, configure SSL content rules for each server with a HREF on each server that points to the SSL Content rules VIP.

You may also need to make some modifications to configurations of web applications on secured servers s1 and s2.

Also a content rule with a sticky configuration set to advanced-balance cookies requires all clients to enable cookies on their browser.

Configure

In this section, you are presented with the information to configure the features described in this document.

Note: Use the Command Lookup Tool (registered customers only) to obtain more information on the commands used in this section.

Configurations

This document uses this configuration:

  • CSS11XXX with WebNS 5.00 and later - Running Configuration

CSS11XXX with WebNS 5.00 and later - Running Configuration
!Generated on 10/10/2001 18:12:17
 !Active version: ap0500015s
  configure
 !************************** SERVICE************************** 
  service s1
     ip address 10.10.1.101
     active
  service s2
     ip address 10.10.1.102
     active 
 !*************************** OWNER***************************
  owner cookie-ssl
     content layer5cookie
        vip address 10.10.1.66
        protocol tcp
        port 80
        url "/*"
        advanced-balance arrowpoint-cookie
        
!--- Specify a port in the content rule to use this option.
        !--- Port 80 traffic is used here. 
        !--- All clients must enable cookies on their browser.


        add service s1

        add service s2

        active 
     content s1-ssl
        vip address 10.10.1.88
        protocol tcp
        port 443
        application ssl
        add service s1
        active
     content s2-ssl
        vip address 10.10.1.99
        protocol tcp
        port 443
        
        application ssl
        add service s2
        active

 
!--- Use this HREF on server S1 where switching from http to https:


   <A HREF="https://10.10.1.101/applicationpath1/"> secure site s1 </A>

 
!--- Use this HREF on server S2 where switching from http to https:

   <A HREF="https://10.10.1.102/applicationpath2"> secure site s2 </A>

 
!--- In the example, the addresses for servers s1 and s2 must be 
 !--- reachable from the client. If this is not the case, you must add a 
 !--- content rule for each server with a unique publicly routable VIP
 !--- address and one service for each SSL server, as shown here:


     content s1-ssl
         vip address 10.10.1.88
         protocol tcp port 443
         application ssl
         add service s1
         active  

     content s2-ssl
          vip address 10.10.1.99
          protocol tcp port 443
          application ssl
          add service s2
          active


!--- Use this HREF on server s1 where the switch from http to https occurs:

      <A HREF=https://10.10.1.88/applicationpath1/> secure site s1 </A>  

!--- Use this HREF on server s2 where the switch from http to https occurs:  

      <A HREF=https://10.10.1.99/applicationpath2> secure site s2 </A>

Verify

There is currently no verification procedure available for this configuration.

Troubleshoot

There is currently no specific troubleshooting information available for this configuration.

Related Information

Updated: Jan 31, 2006
Document ID: 16202