ACE - HTTPS CLASS MAP CONFIGURATION

Unanswered Question
Nov 20th, 2012

Hi,

We have a secured web site (HTTPS) currently fronted by Cisco ACE 4170, running version A5(1.2). We are trying to use the http class map to manipulate the traffic flow in the following manner:

https://abc.com/ABC/* -> serverfarm#1

https://abc.com/* -> serverfarm#2           (Default)

Tecnically this should not be difficult and below is a sample of our configuration. We have similar configuration working on our non-secured web site (HTTP) However for the secure web site, the https request https://abc.com/ABC/xxx is continued being routed to serverfarm#2 instead of serverfarm#1 which is very frustrating.

We can easily get this working on my F5 LTM within 5 minutes but this Cisco ACE continue to frustrate me...Appreciate if any expert on Cisco ACE can help to advise on our configuration.. Thanks.

=========================================================

!

serverfarm host serverfarm#1

predictor leastconns

probe https_probe

rserver rs_server#1

  inservice

rserver rs_server#2

  inservice

!

serverfarm host serverfarm#2

predictor leastconns

probe https_probe

rserver rs_server#3

  inservice

rserver rs_server#4

  inservice

!

sticky http-cookie STICKY_HTTPS_serverfarm#1

cookie insert browser-expire

timeout 15

replicate sticky

serverfarm serverfarm#1

!

sticky http-cookie STICKY_HTTPS_serverfarm#2

cookie insert browser-expire

timeout 15

replicate sticky

serverfarm serverfarm#2

!

class-map type http loadbalance match-any class-map-serverfarm#1

2 match http url /ABC/.*

!

policy-map type loadbalance first-match vs_serverfarm_https

class class-map-serverfarm#1

  sticky-serverfarm STICKY_HTTPS_serverfarm#1

  insert-http x-forward header-value "%is"

  ssl-proxy client ssl_serverfarm

class class-default

  sticky-serverfarm STICKY_HTTPS_serverfarm#2

  insert-http x-forward header-value "%is"

  ssl-proxy client ssl_serverfarm

!

=========================================================

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Average Rating: 0 (0 ratings)
kanwalsi Wed, 11/21/2012 - 05:15

Hi Dave,

I see you are using ACE for SSL initiation i.e front end is clear text and back-end should be https. So if you are not using ACE for SSL offloading then ACE by no means can have a look at HTTP header at the front end and hence everything is being sent to default serverfarm.  You are not coming on http but HTTPS. For ACE to take decision based on HTTP-HEADER VALUE, ACE should be able to look into it.

Please paste the complete configuration if that is not the case.

Regards,

Kanwal

davengsingtel Wed, 11/21/2012 - 22:43

Kanwaljeet,

Yes, we are using ACE for SSL termination i.e. front end is https and back-end is also https.

We are doing end-to-end encryption as our IT security and audit wanted end-to-end encryption between the client and servers. ACE should be able to look at the HTTP header at the front end since the client SSL session is terminate on the ACE.

Below is an extract of the configuration, I've leave out the remaining configuration which is not required.

=========================================================

!

serverfarm host serverfarm#1

predictor leastconns

probe https_probe

rserver rs_server#1

  inservice

rserver rs_server#2

  inservice

!

serverfarm host serverfarm#2

predictor leastconns

probe https_probe

rserver rs_server#3

  inservice

rserver rs_server#4

  inservice

!

sticky http-cookie STICKY_HTTPS_serverfarm#1

cookie insert browser-expire

timeout 15

replicate sticky

serverfarm serverfarm#1

!

sticky http-cookie STICKY_HTTPS_serverfarm#2

cookie insert browser-expire

timeout 15

replicate sticky

serverfarm serverfarm#2

!

class-map match-all vs_serverfarm

  2 match virtual-address 10.178.50.140 tcp eq https

!

class-map type http loadbalance match-any class-map-serverfarm#1

2 match http url /ABC/.*

!

policy-map type loadbalance first-match vs_serverfarm_https

class class-map-serverfarm#1

  sticky-serverfarm STICKY_HTTPS_serverfarm#1

  insert-http x-forward header-value "%is"

  ssl-proxy client ssl_serverfarm

class class-default

  sticky-serverfarm STICKY_HTTPS_serverfarm#2

  insert-http x-forward header-value "%is"

  ssl-proxy client ssl_serverfarm

!

policy-map multi-match PRODWEB_POLICY

  class vs_serverfarm

    loadbalance vip inservice

    loadbalance policy vs_serverfarm_https

    loadbalance vip icmp-reply active

    nat dynamic 100 vlan 100

    ssl-proxy server ssl_serverfarm

=========================================================

kanwalsi Thu, 11/22/2012 - 00:39

Hi Dave,

The configuration looks fine. It should work and as you say the same exact configuration is working fine using HTTP.

Can you send me the  output of show service policy detail. It may be that regex for URL is not matching with what client is coming with.

Regards,

Kanwal

davengsingtel Thu, 11/22/2012 - 02:35

Kanwai,

It's working now after we take the virtual server "out of service" and bring it back to "in service".

Is this required or do I need to reset certain parameter for this change to be effected? I shld be able to implement this change on the fly without bringing down the entire web site.

kanwalsi Thu, 11/22/2012 - 03:18

Hi Dave,

Normally when you add a new cert (in case your existing cert has expired) then in that case you need to bounce the SSL-proxy or loadbalance policy itself for the new changes to take place. In your case what exact changes did you make to existing configuration? I suppose you added ssl-proxy client to  the LB policy map. I am not sure if that should require taking VIP out-of-service and bring it to in-service. May be need to test this out.

Regards,

Kanwal

davengsingtel Thu, 11/22/2012 - 05:04

Kanwal,

The only changes made to the existing virtual server is to add the http class map to route any https requests for /ABC/* to serverfarm#1. To take out the virtual server out of service is not a major issue except that i will need  downtime to effect the change.It took me a while to realize this as i was certain that there was nothing wrong with my config.

kanwalsi Thu, 11/22/2012 - 05:20

Hi Dave,

Yes you are right. There was nothing wrong with the configuration although i  did suspect that regex configured may not be matching with what client was coming with. If you configured a new class map, then you called this class-map under policy map and same policy map is associated with multi-match policy already. I think this needs to be tested but generally adding new certs to the ssl-proxy does require removing and readdind ssl-proxy service or take out vip out of service and put it back in "inservice". Because you already have old cert loaded in the memory. I will try and test this in a day or two to confirm.

Regards,

Kanwal

Actions

Login or Register to take actions

This Discussion

Posted November 20, 2012 at 6:38 PM
Stats:
Replies:7 Avg. Rating:
Views:801 Votes:0
Shares:0

Related Content

Discussions Leaderboard

Rank Username Points
1 1,551
2 369
3 333
4 228
5 212
Rank Username Points
5