05-25-2011 03:46 AM
I am having problems getting this to work.
I am trying to laod balance a site that is both http and https.This is working fine.
When you are running the Web app at a certain point it switches to HTTPS. This causes the ACE to loadbalance the HTTPS Traffic, but most of the time it does not load balance to the same server so the information that is normally kept ont he server is not transfer to the new server. I need a way to keep the same sticky cookie for both http and https.
These are my current configs. They are not correct as I get a different cooke for both HTTP and HTTPS. Is it possible to use the same cookie for both?
probe https HTTPS_Probe3
interval 10
passdetect interval 10
ssl version all
request method get url https://www.TEST.com
expect status 200 200
open 1
probe http HTTP_Probe3
interval 10
passdetect interval 10
request method get url http://www.TEST.com
expect status 200 200
open 1
rserver host WebPD01
ip address 172.16.1.6
weight 2
inservice
rserver host WebPD02
ip address 172.16.1.7
inservice
rserver host WebPD03
ip address 172.16.1.75
inservice
rserver host WebPD04
ip address 172.16.1.76
inservice
rserver host WebPD05
ip address 172.16.1.77
inservice
rserver host WebPD06
ip address 172.16.1.78
inservice
serverfarm host WebPD_SF
probe HTTPS_Probe3
rserver WebPD01 443
inservice
rserver WebPD02 443
inservice
rserver WebPD03 443
inservice
rserver WebPD04 443
inservice
rserver WebPD05 443
inservice
rserver WebPD06 443
inservice
serverfarm host WebPD_SF80
probe HTTP_Probe3
rserver WebPD01 80
inservice
rserver WebPD02 80
inservice
rserver WebPD03 80
inservice
rserver WebPD04 80
inservice
rserver WebPD05 80
inservice
rserver WebPD06 80
inservice
parameter-map type ssl PM3
session-cache timeout 300
queue-delay timeout 1
sticky http-cookie TESTlb WebPD_sticky
cookie insert browser-expire
replicate sticky
serverfarm WebPD_SF
sticky http-cookie TESTlb WebPD_sticky80
cookie insert browser-expire
replicate sticky
serverfarm WebPD_SF80
ssl-proxy service SSL_CLIENT_PD
ssl advanced-options PM3
ssl-proxy service SSL_SERVER_PD
key TEST.pem
cert TEST.pem
ssl advanced-options PM3
class-map type http loadbalance match-all HTTP_PD
2 match http url .*
class-map type http loadbalance match-all SSL_PD
description SSL Layer 7 for Web PD
2 match http url .*
class-map match-all WebPD_VS
2 match virtual-address 172.16.2.20 tcp eq https
class-map match-all WebPD_VS80
2 match virtual-address 172.16.2.20 tcp eq www
class-map type management match-any www
201 match protocol snmp any
202 match protocol telnet any
203 match protocol ssh any
204 match protocol icmp any
205 match protocol https any
206 match protocol http any
policy-map type management first-match www
class www
permit
policy-map type loadbalance first-match WebPD_VS-l7slb
class SSL_PD
sticky-serverfarm WebPD_sticky
ssl-proxy client SSL_CLIENT_PD
policy-map type loadbalance first-match WebPD_VS-l7slb80
class HTTP_PD
sticky-serverfarm WebPD_sticky80
policy-map multi-match WebPD
class WebPD_VS
loadbalance vip inservice
loadbalance policy WebPD_VS-l7slb
loadbalance vip icmp-reply
nat dynamic 1 vlan 302
ssl-proxy server SSL_SERVER_PD
class WebPD_VS80
loadbalance vip inservice
loadbalance policy WebPD_VS-l7slb80
loadbalance vip icmp-reply
nat dynamic 1 vlan 302
interface vlan 302
ip address 172.16.2.4 255.255.255.0
alias 172.16.2.5 255.255.255.0
peer ip address 172.16.2.3 255.255.255.0
fragment chain 112
access-group input ACL
nat-pool 1 172.16.2.200 172.16.2.201 netmask 255.255.255.0 pat
service-policy input www
service-policy input WebPD
no shutdown
05-25-2011 05:27 AM
If you want to use sticky LB based on cookie, there are a couple of things to you can do, but ideally you would setup dynamic cookie learning and stick based on session cookie set on the webserver. The server cookie will be set and maintained for this session and all client traffic (HTTP and HTTPS) presented with this server specific session cookie will be persisted on. The only thing you will need to be careful of is if a subsequent response from server instructs the client to make a new HTTP request (i.e. location header, etc.). In this case you would need to work with your web/app folks to setup site specific redirects on the webservers themselves..
--Configuration guide on how to configure this option:
Another possible option, and again this is without me knowing the application flow, would be to make all traffic SSL to a single VIP policy.. Meaning, setup a redirect for the site if a connection is first established via HTTP (this can be done via a redirect rserver) to redirect the client to HTTPS. If this is done, you will also want to ensure a server generated location header doesn't cause the client to try and make a new http connection, you can re-write the location header to be maintained as ssl (done via action-list command / to do ssl rewrite as server response comes back through -200ok) -
--Config guide for redirect:
--Config Guide for ssl - rewrite:
For both of the above options you will need to create a parameter map to instruct the ace to do persistence rebalance..
--Configuration Guide for Persistence rebalance:
A less "granular" method would be to stick based on IP - this would work whether traffic is HTTP or HTTPS as the ACE creates a sticky entry based on clients source IP. This has it's own caveats - e.g., mega proxy and/or proxy where multiple clients are represented by a single proxy IP - creates "clumping" ..
HTH.
05-25-2011 07:23 AM
Ok, I got this setup and started using a Session ID provided by the Server, I have ensured the cookies are the same, but it still loadbalances the connection to a different server when I switch to https.
The blelow sticky Databse shows the Stickys do not line up between HTTP and HTTPS
sticky group : WebPD_sticky80
type : HTTP-COOKIE
timeout : 720 timeout-activeconns : FALSE
sticky-entry rserver-instance time-to-expire flags
---------------------+--------------------------------+--------------+-------+
16654257725771741312 WebPD02:80 37607 -
17337303565750424621 WebPD02:80 37702 -
2959707193734522029 WebPD02:80 37757 -
17513740319438450763 WebPD02:80 37826 -
17314163098156928995 WebPD02:80 37843 -
15349963942543434403 WebPD02:80 38166 -
5111478708859931171 WebPD03:80 38169 -
12756813240786919277 WebPD04:80 41136 -
3020038815990512745 WebPD04:80 41311 -
16260417067658327613 WebPD03:80 41394 -
6643432373729599067 WebPD03:80 41412 -
5789217862541186996 WebPD04:80 41476 -
12732748354722635914 WebPD05:80 41512 -
10083444411992074718 WebPD06:80 41763 -
10756774743654344231 WebPD06:80 41779 -
13517627829347016284 WebPD02:80 42913 -
14694560347427331811 WebPD02:80 42961 -
14294973373842793914 WebPD03:80 43154 -
sticky group : WebPD_sticky
type : HTTP-COOKIE
timeout : 720 timeout-activeconns : FALSE
sticky-entry rserver-instance time-to-expire flags
---------------------+--------------------------------+--------------+-------+
16654257725771741312 WebPD01:443 37690 -
17337303565750424621 WebPD02:443 37712 -
2959707193734522029 WebPD02:443 37769 -
17314163098156928995 WebPD02:443 37887 -
5111478708859931171 WebPD03:443 38173 -
16260417067658327613 WebPD03:443 38220 -
12756813240786919277 WebPD03:443 41163 -
3020038815990512745 WebPD03:443 41327 -
6643432373729599067 WebPD03:443 41440 -
12732748354722635914 WebPD04:443 41527 -
10083444411992074718 WebPD04:443 41717 -
10756774743654344231 WebPD04:443 41802 -
5789217862541186996 WebPD04:443 42930 -
14294973373842793914 WebPD01:443 42985 -
05-25-2011 07:52 AM
The behavior you describe is a function of how the web server is setting session cookies. The web application is instructing the client to setup a new *session* via HTTPS (new session = new session cookie). The client browser will then present the new cookie and the ACE will learn the new cookie and make a new LB decsion.
The function of maintaining site persistence with the client -> ace -> app (http/https) in the environment you apps are operating requires a session cookie set and managed by a 'single sign on' web plugin/app.. This is a common requirement for sites that require clients to maintain secured identity as well as application persistence as client is redirected to different app teirs in the web structure..
Reference for single sign on - I think you web app folks should be able to help you with this..
http://en.wikipedia.org/wiki/Single_sign-on
If SSO is possible by your webapplication, then levarging session cookie learning on the ACE will provide you the fucntionality and persistence required.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide