LocalDirector is now End-of-Sale. Refer to the Cisco LocalDirector 400 Series bulletins for more information.
This document explains how to configure HTTP (non-secure site) to HTTPS (secure site) redirection on the Cisco Local Director. Please note the limitations in this example configuration.
For more information on document conventions, see the Cisco Technical Tips Conventions.
There are no specific prerequisites for this document.
The information in this document is based on the software and hardware versions below.
Local Director 416
Local Director Software Release 4.2.1
Microsoft Internet Explorer 5.5
Netscape Communicator 4.7
The information presented in this document was created from devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration. If you are working in a live network, ensure that you understand the potential impact of any command before using it.
This document uses the network setup shown in the diagram below.
There is a well known problem of keeping a session bound to one physical real server after the session is setup on HTTP (open) transport and later moved to HTTPS (secure) transport protocol. In this case, the HTTP redirection should be setup at the application level. The server can send a redirect (either a 302 or an HREF embedded in the actual web page itself) to HTTP, so no load balancing takes place at the Local Director.
Another possible solution would be to switch to HTTPS sooner, and perform the session opening encrypted. This is preferred also for encrypting the login username and password. If you keep the whole session running via HTTPS, the generic sticky can ensure that the same server will be used for a client.
The second solution and configuration is described in this document. The HTTP traffic is limited to first contact with the site (the client can type simple site name to address bar). When reaching Local Director, the browser receives a 302 redirect message with the URL configured, including the HTTPS tag, so there is the complete name of the server to reach. The session (on application level) is built from the beginning with the secure server (the real servers do not handle HTTP at all). Tthe session continues with the unique server name, so it is always reaching the same.
The dip, backup, and link commands, as shown in the example, are needed to solve bookmark problem when a user saves a URL with one server name and returns later when the server is down. The configured backup server will serve the session. If you expect to have a part of the session (on application level) handled via HTTP, then there is no possibility on the Local Director (or any other network device) to link the HTTPS connection to any of the preexisting HTTP connections. The only commonly used parameter can be the source IP address. The source IP address becomes unusable when you consider HTTP proxy, but direct HTTPS connections. All information stored in the URL or HTTP header (such as cookies) is encrypted, thus not accessible.
The only solution in this case is that the application itself uses specific server name when switching to HTTPS. As the application runs on the real server, and generates the HTTPS URL, it is the only place where the issue can be solved. The server simply sends a URL directed to the server itself. With the help of the backup command, you can solve the bookmark problem, as above. A disadvantage of both solutions is a need for different Secure Socket Layer (SSL) certificates in both real servers. The number of HTTP/HTTPS servers is not limited, and the Local Director remains balancing the initial session requests. After the session is established, however, the clients refer to one server only.
Use the following steps to configure HTTP to HTTPS redirection on the Local Director:
Create a port-bound virtual IP (VIP) address and enter it in the Domain Name System (DNS). For example:
virtual 172.18.124.209:80:0:tcp is
Create a direct IP (DIP) address for each real server that will accept calls for this VIP address. Use an extra IP address in the first part of the statement, such as in the following:
direct-ip 172.18.124.211:443:0:tcp 172.18.124.206:443:0:tcp is direct-ip 172.18.124.212:443:0:tcp 172.18.124.207:443:0:tcp is
The system will create the following:
real 172.18.124.206:443:0:tcp is real 172.18.124.207:443:0:tcp is bind 172.18.124.211:443:0:tcp 172.18.124.206:443:0:tcp bind 172.18.124.212:443:0:tcp 172.18.124.207:443:0:tcp
Note: For port-bound or port-specific VIPs, DIPS, and real IP addresses, an additional IP address is needed for every real server to allow for continued outbound connections to the real IP addresses. Also, this additional address allows for safe VIP addresses if any TCP reset (RST) packets are sent for ports that are not to be load-balanced or redirected. Calls directed to the DIP addresses by their true address would be allowed while using other IP addresses for the DIP address' virtual.
Create a URL redirect for each real server. These URLs are where the client will be redirected when a VIP address is hit. For example:
url s2 https://www.mysecureserver.com 302 url s1 https://www.yoursecureserver.com 302
Create a backup command for each DIP address to the common VIP address to solve potential bookmarking problems. If a client bookmarks the URL of a DIP address and that DIP address (real server) is unavailable (FAILED), then the backup command is used to call the VIP address again.
backup 172.18.124.211:443:0:tcp 172.18.124.212:443:0:tcp backup 172.18.124.212:443:0:tcp 172.18.124.211:443:0:tcp
Note: You cannot backup a TCP/443 with a TCP/80, therefore, you have two options:
Backup a DIP address with another DIP address, or in a full mesh sytle (each DIP address has a backup to every other DIP address).
Backup a DIP address with a VIP/443 that is bound to the real/443.
Bind the VIP address to each URL command. For example:
bind 172.18.124.209:80:0:tcp s1 bind 172.18.124.209:80:0:tcp s2
Create a link command for each URL to the first part of the DIP address.
This creates an association between the DIP address and the URLs associated with that nickname. The link ensures that Local Director does not redirect clients to a failed DIP address, which is mapped one-to-one with a real server. If a DIP address fails, do not redirect to the URL that would send a call to the failed DIP address.
link s2 172.18.124.211:443:0:tcp link s1 172.18.124.212:443:0:tcp
This section provides information you can use to confirm your configuration is working properly.
show version - Displays the software version the Local Director is running.
show configuration - Displays the current running configuration on the Local Director.
show dip - Displays DIP pairings.
show real - Displays the real servers' statistics and states.
show statistics - Displays the real and virtual server statistics.
show syslog - Displays log messages to the syslog server.
show url - Displays connection information to the URLs.
The following is the output of the show version command:
localdirector#show version LocalDirector 416 Version 4.2.1
The following is the output of the show configuration command:
localdirector#show configuration Building configuration... : Saved : LocalDirector 416 Version 4.2.1 syslog output 23.7 no syslog console enable password 000000000000000000000000000000 encrypted hostname localdirector no shutdown ethernet 0 no shutdown ethernet 1 shutdown ethernet 2 interface ethernet 0 auto interface ethernet 1 auto interface ethernet 2 auto mtu 0 1500 mtu 1 1500 mtu 2 1500 multiring all no secure 0 no secure 1 no secure 2 no ping-allow 0 no ping-allow 1 no ping-allow 2 ip address 172.18.124.210 255.255.255.0 route 0.0.0.0 0.0.0.0 172.18.124.1 1 arp timeout 30 no rip passive rip version 1 failover ip address 0.0.0.0 no failover failover hellotime 30 password 636973636f004661696c6f766572204e encrypted snmp-server enable traps snmp-server community public no snmp-server contact no snmp-server location virtual 172.18.124.209:80:0:tcp is real 172.18.124.206:443:0:tcp is real 172.18.124.207:443:0:tcp is direct-ip 172.18.124.211:443:0:tcp 172.18.124.206:443:0:tcp is direct-ip 172.18.124.212:443:0:tcp 172.18.124.207:443:0:tcp is url s2 https://www.mysecureserver.com 302 url s1 https://www.yoursecureserver.com 302 backup 172.18.124.211:443:0:tcp 172.18.124.212:443:0:tcp backup 172.18.124.212:443:0:tcp 172.18.124.211:443:0:tcp bind 172.18.124.211:443:0:tcp 172.18.124.206:443:0:tcp bind 172.18.124.212:443:0:tcp 172.18.124.207:443:0:tcp bind 172.18.124.209:80:0:tcp s1 bind 172.18.124.209:80:0:tcp s2 link s2 172.18.124.211:443:0:tcp link s1 172.18.124.212:443:0:tcp : end [OK]
The following is the output of the show dip command:
localdirector#show dip Direct IPs: Virtual Real Conns State Predictor Slowstart 172.18.124.211:443:0:tcp 172.18.124.206:443:0:tcp 0 IS leastconns roundrobin* 172.18.124.212:443:0:tcp 172.18.124.207:443:0:tcp 0 IS leastconns roundrobin*
The following is the output of the show real command:
localdirector#show real Real Machines: No Answer TCP Reset DataIn Machine Connect State Thresh Reassigns Reassigns Conns (DIP) 172.18.124.206:443:0:tcp 1 IS 8 0 0 0 (DIP) 172.18.124.207:443:0:tcp 1 IS 8 0 0 0
The following is the output of the show statistics command:
localdirector#show statistics Real Machine(s) Bytes Packets Connections (DIP) 172.18.124.206:443:0:tcp 480 8 1 (DIP) 172.18.124.207:443:0:tcp 240 4 1 Virtual Machine(s) Bytes Packets Connections (DIP) 172.18.124.211:443:0:tcp 480 8 1 (DIP) 172.18.124.212:443:0:tcp 240 4 1 172.18.124.209:80:0:tcp 10215 80 6
The following is the output of the show syslog command:
OUTPUT ON (23.7) CONSOLE ON <189> July 2 13:07:40 LD-NOTICE Begin Configuration: reading from terminal <189> July 2 13:07:45 LD-NOTICE End Configuration: OK <186> July 2 13:08:00 LD-CRIT Switching '172.18.124.209:80:0:tcp' from 'slowstart' to 'leastconns' <186> July 2 13:10:25 LD-CRIT Switching '172.18.124.211:443:0:tcp' from 'slowstart' to 'leastconns' <186> July 2 13:10:41 LD-CRIT Switching '172.18.124.212:443:0:tcp' from 'slowstart' to 'leastconns' localdirector#
The following is the output of the show url command:
localdirector#show url Urls: Id Connect Rcode State Url s2 2 302 IS https://www.mysecureserver.com s1 2 302 IS https://www.yoursecureserver.com
There is currently no specific troubleshooting information available for this configuration.
The Cisco Support Community is a forum for you to ask and answer questions, share suggestions, and collaborate with your peers.
Refer to Cisco Technical Tips Conventions for information on conventions used in this document.