Re: ACE with SSL Termination issue

silk · ‎03-10-2011

Hello,

I've configured a bridge mode context to do ssl termination for one specific VIP, port 443 outside to port 80 inside.

The problem I'm facing is something that resembles a MTU issue:

if I browse for simple html pages everything works fine, but if I start a file download (via HTTPS) the connection times out.

If I remove the ssl-proxy statement from the service policy, everything is all right and the file trasfer (via HTTP) works flawlessly.

Any ideas?

Thanks in advance.

S.

amacuz · ‎03-10-2011

Hi Silk,

have you tried to spot at which stage the connection times out?

Try to collect captures from the client and server and see what may be the problem.

Does the SSL phase complete?

Which version of the ACE are you running?

Alessandro

silk · ‎03-10-2011

Alessandro,

thanks for the reply.

I'm already doing some packet captures to check the connection phases (on the ACE and on the client - I've got no access to the servers) but

everything *looks* regular... for some reason the return traffic from the balancer seems to just hang somewhere, but not happening if the ACE is not ssl-proxing the flows.

I can see the replies coming from the server in cleartext but...

On the client browser side, the ssl handshake works normally, the cert is received from the LB and there is no warning in the browser.

ACE Module version is:

Software

loader: Version 12.2[123]

system: Version A2(1.6a) [build 3.0(0)A2(1.6a) adbuild_08:46:04-2009/10/16_/auto/adbu-rel4/rel_a2_1_6_throttle/REL_3_0_0_A2_1_6

S.

silk · ‎03-11-2011

This is the relevant config of the LB:

access-list ROUTING line 8 extended permit ip any any

probe tcp TCP_80

interval 10

passdetect interval 10

rserver host 1.1.1.24

ip address 1.1.1.24

inservice

rserver host 1.1.1.25

ip address 1.1.1.25

inservice

ssl-proxy service PROXY_webservice

key ACE_Key.pem

cert webservice.cer

serverfarm host 10.1.1.23_TCP_443

probe TCP_80

rserver 1.1.1.24 80

inservice

rserver 1.1.1.25 80

inservice

sticky ip-netmask 255.255.255.255 address source Sticky_10.1.1.23_TCP_443

timeout 10

replicate sticky

serverfarm 10.1.1.23_TCP_443

class-map type management match-any ICMP-RESPONSE

2 match protocol icmp any

class-map match-all Class_10.1.1.23_TCP_443

2 match virtual-address 10.1.1.23 tcp eq https

policy-map type loadbalance generic first-match Policy_10.1.1.23_TCP_443

class class-default

sticky-serverfarm Sticky_10.1.1.23_TCP_443

policy-map multi-match LB-Policy

class Class_10.1.1.23_TCP_443

loadbalance vip inservice

loadbalance policy Policy_10.1.1.23_TCP_443

loadbalance vip icmp-reply

ssl-proxy server PROXY_webservice

interface vlan 2

description webservice_to_SERVER

bridge-group 1

no normalization

mac-sticky enable

no icmp-guard

access-group input ROUTING

service-policy input ICMP-RESPONSE

no shutdown

interface vlan 22

description webservice_to_FW

bridge-group 1

no normalization

mac-sticky enable

no icmp-guard

access-group input ROUTING

service-policy input ICMP-RESPONSE

service-policy input LB-Policy

no shutdown

interface bvi 1

ip address 1.1.1.21 255.255.255.240

alias 1.1.1.20 255.255.255.240

peer ip address 1.1.1.22 255.255.255.240

description webservice_BRIDGE

no shutdown

Key and Cert are installed and verified correctly.

Packet sniffing shows cypher exchange successful and the certificate is ok on the browser side.

Still the transfer hangs.

Removing the "ssl-proxy server PROXY_webservice" from the service policy and going cleartext on port tcp/443

shows that everything else is working correctly and there are no hangs.

Is there something I can check to clear if the LB is acting weird?

This LB is one of a hot standby couple, switching to the secondary one did not solve the issue.

Thanks.

silk · ‎03-22-2011

Tip for the record.

issue has been solved by myself simply:

policy-map type loadbalance ~~generic~~ first-match Policy_10.1.1.23_TCP_443

class class-default

sticky-serverfarm Sticky_10.1.1.23_TCP_443

Bye!