Solved: HTTP-Cookie sticky not working.

grichardson661 · ‎02-02-2012

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

!

Cesar Roque · ‎02-02-2012

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

chrhiggi · ‎03-21-2012

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

pablo.nxh · ‎02-02-2012

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

Cesar Roque · ‎02-02-2012

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

grichardson661 · ‎02-03-2012

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

ravi281278 · ‎02-05-2012

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

nz78au · ‎03-08-2012

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

chrhiggi · ‎03-21-2012

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

grichardson661 · ‎03-30-2012

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.

grichardson661 · ‎03-30-2012

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

chrhiggi · ‎03-30-2012

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

grichardson661 · ‎04-02-2012

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

chrhiggi · ‎04-02-2012

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

grichardson661 · ‎04-04-2012

Chris, thanks!