Buy or Renew
Buy or Renew
Cisco + Splunk: It’s a new day for your data. Learn more.
 
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
4317
Views
0
Helpful
12
Replies

HTTP-Cookie sticky not working.

Go to solution
grichardson661
Level 1
Level 1

‎02-02-2012 12:13 AM

Hey,

I have a requirement to load balance OWA 2010 inbound connectivity to 2 CAS servers using a ACE 4710 with sticky sessions enabled.

The CAS servers are currently responding on 80 or 443 at this moment in time. Eventually I want to off load the SSL to the ACE 4710, its currently running on the CAS servers. I need to enable sticky sessions to keep the session to the same CAS server for each internet based connection. I also have a proxy enabled for inbound connectivity so I cannot use source IP.

Here is my configuration but it doesn’t seem to be working, i am currently testing with port 80 connections not SSL. Anyone any ideas? Cheers!

serverfarm host INHOUSE-EXCHANGE-OWA-vFARM

predictor response app-req-to-resp samples 4

probe 443

probe HTTP-PROBE

rserver INHOUSE-TEST-CAS01-SVR

   inservice

rserver INHOUSE -TEST-CAS02-SVR

   inservice

!

sticky http-cookie SessionID INHOUSE-EXCHANGE-OWA-vFARM-STICKY

cookie insert

serverfarm INHOUSE-EXCHANGE-OWA-vFARM

!

class-map match-all INHOUSE-EXCHANGE-OWA-CLASS-MAP-443

2 match virtual-address 192.158.100.100 tcp eq https

class-map match-all INHOUSE-EXCHANGE-OWA-CLASS-MAP-80

2 match virtual-address 192.158.100.100 tcp eq www

!

policy-map type loadbalance http first-match INHOUSE-EXCHANGE-OWA-POLICY

class class-default

   sticky-serverfarm INHOUSE-EXCHANGE-OWA-vFARM-STICKY

!

policy-map multi-match VIP-POLICY

   class INHOUSE-EXCHANGE-OWA-CLASS-MAP-443

   loadbalance vip inservice

   loadbalance policy INHOUSE-EXCHANGE-OWA-POLICY

   loadbalance vip icmp-reply

class INHOUSE-EXCHANGE-OWA-CLASS-MAP-80

   loadbalance vip inservice

   loadbalance policy INHOUSE-EXCHANGE-OWA-POLICY

   loadbalance vip icmp-reply

!

Labels:
0 Helpful
2 Accepted Solutions

Accepted Solutions

Go to solution
Cesar Roque
Level 4
Level 4

‎02-02-2012 05:28 PM

Hi,

Try to configure a L7 class-map, something like this:

policy-map type loadbalance http first-match INHOUSE-EXCHANGE-OWA-POLICY

  class L7

    sticky-serverfarm INHOUSE-EXCHANGE-OWA-vFARM-STICKY

class-map type http loadbalance match-all L7

   match http url .*

Cesar R

--------------------- Cesar R ANS Team

View solution in original post

0 Helpful

Go to solution
chrhiggi
Level 3
Level 3

‎03-21-2012 10:35 AM

Take a quick sniffer trace on the client using wireshark and filter on the ip address of the vip (ip.addr == 192.158.100.100)  Do you see anything being sent on port 443, or is it all on port 80?  If you see anything at all on port 443, this won't work until you decypt the SSL on ACE.  If you do see 100% port 80 traffic, then you have a problem with cookies disappearing or changing mid-flow. 

Why the port 443 mix won't work:

Its encrypted! ACE can't inspect for or insert a cookie if the traffic flow is not HTTP.  You are sending all http and https traffic to INHOUSE-EXCHANGE-OWA-POLICY which points to cookie sticky.  That automatically makes ACE terminate the TCP connection with the client, inspect the http header, then make a loadbalancing decision based on wether there was a valid cookie or not.  When ACE terminates the SSL connection, instead of recieving a HTTP GET/POST/etc. the client sends an SSL Client Hello packet.  ACE will see this is not HTTP and will send a reset back to the client. 

If you created a new policymap type loadbalance and pointed the SSL traffic directly to the serverfarm "INHOUSE-EXCHANGE-OWA-vFARM" , you would still only have a 50% chance of landing the SSL session on the same rserver as the port 80 traffic.  Hence, you really need to decrypt it to make it work.

To troubleshoot the cookie issue if it is all port 80 traffic:

You will be able to see set-cookie: SessionID=R being set in the server response and cookie: SessionID=R in the cookie the client is supplying back.  Within a single TCP session, ACE only puts the set-cookie in the first response the server sends, as well, it only checks the client cookie in the first client request.  If the client is switching cookies mid-flow, or you need it to set the cookie in every server response, enable "persistance-rebalance" under an http parameter map and apply it to the port 80 class under the policy map multimatch.

  There are a few other reasons that ACE could be rejecting the connection (i.e. if the HTTP header is over 4096 bytes, or the HTTP headers are not RFC compliant)  It is not usual for this - but you can check "show stat http" and see if you catch any errors like max parse length or static parse errors.  Again, under the http parameter map, you can tweak values and what to do in cirucumstances like this.

Hope this helps!

Regards,

Chris Higgins

View solution in original post

0 Helpful
12 Replies 12

Go to solution
pablo.nxh
Level 3
Level 3

‎02-02-2012 10:08 AM

Hello there,

A couple of questions

How did you find out this is not working? Cookie checking on FF for example?

If this is not your admin context... did you assign sticky resources to the context?

Is stickiness working for a different serverfarm within the same context?

Thanks

__ __

Pablo

0 Helpful

Go to solution
Cesar Roque
Level 4
Level 4

‎02-02-2012 05:28 PM

Hi,

Try to configure a L7 class-map, something like this:

policy-map type loadbalance http first-match INHOUSE-EXCHANGE-OWA-POLICY

  class L7

    sticky-serverfarm INHOUSE-EXCHANGE-OWA-vFARM-STICKY

class-map type http loadbalance match-all L7

   match http url .*

Cesar R

--------------------- Cesar R ANS Team
0 Helpful

Go to solution
grichardson661
Level 1
Level 1
In response to Cesar Roque

‎02-03-2012 04:31 AM

Hi,

@ Pablo, we knew it wasn't working because we was not able to authenticate with OWA. If we put one of the two CAS rservers in standby authentication worked and we was able to send and retrieve mail. Bring the both rservers back in service and OWA authentication fails.

@ Cesar, yes this worked for port 80 connections (obviously not 443 because the payload in encrypted), seems cookie-insert sticky sessions only works with layer 7 load balancing then?

Next step, off load SSL to the ACE. Should be interesting

0 Helpful

Go to solution
ravi281278
Level 1
Level 1
In response to grichardson661

‎02-05-2012 09:48 PM

Hi, Please dont use the below policy if u are not going to implement SSL in ACE.

class-map match-all INHOUSE-EXCHANGE-OWA-CLASS-MAP-443

2 match virtual-address 192.158.100.100 tcp eq https

If u are implementing SSL on ACE, then u need to create 2 policy for policy map for loadbalancing  & 2 serverfarms.Also before this u need to plan which type of SSL u wnat to use between clinet & ACE.

Ravi K Sharma

0 Helpful

Go to solution
nz78au
Level 1
Level 1

‎03-08-2012 02:30 PM

Hi, I configured this today and follwing is my working config:

sticky ip-netmask 255.255.255.255 address source cas-ip

  replicate sticky

  serverfarm cas-farm

sticky http-header Authorization cas-rpc-http

  serverfarm cas-farm

sticky http-cookie Cookie owa-sticky

  cookie insert browser-expire

  timeout 60

  replicate sticky

  serverfarm cas-farm

class-map match-all exch-owa-vip

  2 match virtual-address 10.20.50.204 tcp eq https

policy-map type loadbalance first-match exch-OWA-vip

  class class-default

    sticky-serverfarm cas-ip

policy-map type loadbalance first-match exch-owa

  match OUTLOOK_ANYWHERE http header User-Agent header-value "MSRPC"

sticky-serverfarm cas-rpc-http

  class class-default

0 Helpful

Go to solution
chrhiggi
Level 3
Level 3

‎03-21-2012 10:35 AM

Take a quick sniffer trace on the client using wireshark and filter on the ip address of the vip (ip.addr == 192.158.100.100)  Do you see anything being sent on port 443, or is it all on port 80?  If you see anything at all on port 443, this won't work until you decypt the SSL on ACE.  If you do see 100% port 80 traffic, then you have a problem with cookies disappearing or changing mid-flow. 

Why the port 443 mix won't work:

Its encrypted! ACE can't inspect for or insert a cookie if the traffic flow is not HTTP.  You are sending all http and https traffic to INHOUSE-EXCHANGE-OWA-POLICY which points to cookie sticky.  That automatically makes ACE terminate the TCP connection with the client, inspect the http header, then make a loadbalancing decision based on wether there was a valid cookie or not.  When ACE terminates the SSL connection, instead of recieving a HTTP GET/POST/etc. the client sends an SSL Client Hello packet.  ACE will see this is not HTTP and will send a reset back to the client. 

If you created a new policymap type loadbalance and pointed the SSL traffic directly to the serverfarm "INHOUSE-EXCHANGE-OWA-vFARM" , you would still only have a 50% chance of landing the SSL session on the same rserver as the port 80 traffic.  Hence, you really need to decrypt it to make it work.

To troubleshoot the cookie issue if it is all port 80 traffic:

You will be able to see set-cookie: SessionID=R being set in the server response and cookie: SessionID=R in the cookie the client is supplying back.  Within a single TCP session, ACE only puts the set-cookie in the first response the server sends, as well, it only checks the client cookie in the first client request.  If the client is switching cookies mid-flow, or you need it to set the cookie in every server response, enable "persistance-rebalance" under an http parameter map and apply it to the port 80 class under the policy map multimatch.

  There are a few other reasons that ACE could be rejecting the connection (i.e. if the HTTP header is over 4096 bytes, or the HTTP headers are not RFC compliant)  It is not usual for this - but you can check "show stat http" and see if you catch any errors like max parse length or static parse errors.  Again, under the http parameter map, you can tweak values and what to do in cirucumstances like this.

Hope this helps!

Regards,

Chris Higgins

0 Helpful

Go to solution
grichardson661
Level 1
Level 1
In response to chrhiggi

‎03-30-2012 01:48 AM

Hi Chris, thansk for the detailed updated. And yes we got to the bottom of it and off loaded the SSL a while back and it works a treat.

0 Helpful

Go to solution
grichardson661
Level 1
Level 1
In response to chrhiggi

‎03-30-2012 01:55 AM

Another question while i'm here. When offloading the SSL and after the decryption has took place the ACE will forward the request to the web server on port 80, i get that. But in this scenario how would IIS know the connection has still come securely on https 443? For example, after decryption the ACE forwards the packet to the web server on TCP port 80. At that point the web server may say - 'you go and reconnect on 443' causing a never ending loop.

How would the web server (IIS) know the connection has come in securly the ACE is decrypting? I'm guessing the IIS server is looking at the host header which would indicate the connection has come in on 443 by checking https but at the transport layer its still TCP port 80?

Cheers

0 Helpful

Go to solution
chrhiggi
Level 3
Level 3
In response to grichardson661

‎03-30-2012 11:06 AM

Realistically, the server is blissfully unaware of what is going on outside of its own HTTP connection to the ACE.  If the server needs to detect that there is front end SSL going on, you can configure the ACE to insert a header, then pickup the header using a scripting language like ASP/PHP/PERL, etc.  As well, if the server does not care about SSL being done on the front end, it might send a 302 redirect with a http:// link, ACE has the ability to rewrite the location header in this packet using an SSL action list.

Regards,

Chris

0 Helpful

Go to solution
grichardson661
Level 1
Level 1
In response to chrhiggi

‎04-02-2012 04:26 AM

Cheers Chris, really helpful.

One last question, can the same policy-map that matches the server sticky farm be applied to two class-maps (that match 80 or 443) under the single multi-match policy? is this a working model - to keep the user session stuck to the same web server during the 80 to 443 redirect?

Cheers

0 Helpful

Go to solution
chrhiggi
Level 3
Level 3
In response to grichardson661

‎04-02-2012 02:31 PM

Sure can.  One thing many people are unaware of with this type of configuration - With persistance rebalance enabled, ACE only moves the connection to class maps under a single policy map type loadbalance.  Sticky will still work fine between the two ports with SSL decryption as long as the client doesnt do something odd like drop it per protocol.

Regards,

Chris Higgins

0 Helpful

Go to solution
grichardson661
Level 1
Level 1
In response to chrhiggi

‎04-04-2012 01:03 AM

Chris, thanks!

0 Helpful
Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Customers Also Viewed These Support Documents