ACE - HTTP not working when SSL is enabled

Unanswered Question
Jun 4th, 2009

Hello All,

I have this case where HTTP stops working as soon as I configure the policy-map with a ssl-proxy server.

I've attached the config to the thread.

Did anybody ever come across the same issue?

Regards,

Thibault.

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

access-list ALL line 10 extended permit ip any any

parameter-map type http ParseLen

persistence-rebalance

set header-maxparse-length 8000

rserver host PP105

ip address 10.118.228.105

conn-limit max 2000000 min 1500000

inservice

rserver host PP106

ip address 10.118.228.106

conn-limit max 2000000 min 1500000

inservice

ssl-proxy service SSL_PreProd_Server

key PreProd.key

cert PreProd.cert

serverfarm host PreProdServers

predictor leastconns slowstart 18

probe TCP_80

rserver PP105 80

conn-limit max 2000000 min 1500000

inservice

rserver PP106 80

conn-limit max 2000000 min 1500000

inservice

sticky http-cookie preprod-cookie PreProd_Cookie_Sticky_Group

cookie insert

timeout 21

serverfarm PreProdServers

class-map match-any PreProd_Class

3 match virtual-address 10.10.10.12 tcp eq https

4 match virtual-address 10.10.10.12 tcp eq www

policy-map type loadbalance first-match PreProd_MAP

class class-default

sticky-serverfarm PreProd_Cookie_Sticky_Group

policy-map multi-match L4_VIP

class PreProd_Class

loadbalance vip inservice

loadbalance policy PreProd_MAP

loadbalance vip icmp-reply

loadbalance vip advertise active

appl-parameter http advanced-options ParseLen

ssl-proxy server SSL_PreProd_Server

interface vlan 123

description "client Side"

ip address 10.188.1.181 255.255.255.240

alias 10.188.1.179 255.255.255.240

peer ip address 10.118.1.180 255.255.255.240

access-group input ALL

access-group output ALL

service-policy input L4_VIP

no shutdown

interface vlan 456

descriptin "Server side"

ip address 10.188.208.124 255.255.255.224

alias 10.188.208.126 255.255.255.224

peer ip address 10.188.208.125 255.255.255.224

access-group input ALL

access-group output ALL

no shutdown

ip route 0.0.0.0 0.0.0.0 10.188.1.190

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 3 (1 ratings)
Loading.
ciscocsoc Thu, 06/04/2009 - 07:27

Hi,

You need two class-maps because you are treating HTTP and HTTPS differently. In the HTTPS case you are terminating the SSL connection and retransmitting the packets to 80/tcp.

The example below is an extract from a context with similar requirements based on LDAP and LDAPS. We take in both LDAP and LDAPS and connect to the servers only with LDAP.

serverfarm host FARM-LDAP

rserver ldap1 389

inservice

rserver ldap2 389

inservice

rserver ldap3 389

inservice

rserver ldap4 389

inservice

class-map match-any L4VIPCLASS

2 match virtual-address 10.199.253.188 tcp eq 636

class-map match-any L4VIPCLASS-389

2 match virtual-address 10.199.253.188 tcp eq 389

policy-map type loadbalance first-match LB-POLICY

class class-default

serverfarm FARM-LDAP

policy-map multi-match L4POLICY

class L4VIPCLASS

loadbalance vip inservice

loadbalance policy LB-POLICY

loadbalance vip icmp-reply active

loadbalance vip advertise

nat dynamic 1 vlan 395

ssl-proxy server PSERVICE_SERVER

class L4VIPCLASS-389

loadbalance vip inservice

loadbalance policy LB-POLICY

loadbalance vip icmp-reply active

loadbalance vip advertise

nat dynamic 1 vlan 395

HTH

Cathy

deephazz02 Thu, 06/04/2009 - 08:59

So it worked. But that is frustrating because I have another context with HTTP and HTTPS under a single class and they both work without any problem. Sounds silly to say sometimes it works sometimes it doesn't....

Thanks for you answer.

Rgds,

Thibault.

Actions

This Discussion