Solved: ACE: Problem with SSL termination

ciscocsoc · ‎09-01-2009

Dear All,

I'm seeing a strange problem with SSL termination. The context is using Source NAT to backend webservers.

The symptom is that the ACE doesn't send back the "server hello" in response to the "client hello". I get an ACK and then a reset from the client after ca 35 seconds.

The certificates and chains are all valid as far as I can see. I have other contexts with similar configurations working happily.

I've been through the troubleshooting wiki but it hasn't helped. Are there any known reasons for the exhibited behaviour or additional debug steps I can go through? The code level is 2.1.3.

TIA

Cathy

Gilles Dufour · ‎09-03-2009

If we check the client hello received, we can see the counters did not increase.

So, the client hello is probably dropped internally before it gets to the SSL ME.

You can check with 'show np 1 me-stat "-snorm"', 'show np 1 me-stat "-sfp"' and 'show np 1 me-stat "-stcp"' if there are any drops.

Do the same for np 2.

Again repeat the operation and see which counters increase with each failure.

Try to disable normalization if not already done.

Also verify that the hw path is correct with the following command

show np 1 access-l trace vlan in proto 6 source x.x.x.x 0 destaintion x.x.x.x 443

Check the line which says :

......vserver: 0x...

Convert the vserver id to decimal and then do

show cfgmgr internal table l3-vip | i

You should get 2 new id.

One for the policy and one for the class-map.

Verify those id with the command

show cfgmgr internal table class-map

show cfgmgr internal table policy-map

If this corresponds to your config, then this is ok.

If not, remove the policy from the interface, wait 5 sec and reconfigure it.

Gilles.

View solution in original post

Gilles Dufour · ‎09-02-2009

Try without the ssl paramter map (with the cipher). See if that helps.

Also get a 'show stats crypto server' before and after a failure.

G.

ciscocsoc · ‎09-02-2009

Hi Gilles,

Removing the ciphers didn't help. I've attached the output of the "before" and "after" stats.

Thank you

Cathy

Gilles Dufour · ‎09-03-2009

If we check the client hello received, we can see the counters did not increase.

So, the client hello is probably dropped internally before it gets to the SSL ME.

You can check with 'show np 1 me-stat "-snorm"', 'show np 1 me-stat "-sfp"' and 'show np 1 me-stat "-stcp"' if there are any drops.

Do the same for np 2.

Again repeat the operation and see which counters increase with each failure.

Try to disable normalization if not already done.

Also verify that the hw path is correct with the following command

show np 1 access-l trace vlan in proto 6 source x.x.x.x 0 destaintion x.x.x.x 443

Check the line which says :

......vserver: 0x...

Convert the vserver id to decimal and then do

show cfgmgr internal table l3-vip | i

You should get 2 new id.

One for the policy and one for the class-map.

Verify those id with the command

show cfgmgr internal table class-map

show cfgmgr internal table policy-map

If this corresponds to your config, then this is ok.

If not, remove the policy from the interface, wait 5 sec and reconfigure it.

Gilles.

ciscocsoc · ‎09-03-2009

Thank you Gilles. There did seem to be a mismatch between the numbers. Deleting the service-policy and L4POLICY, waiting a few seconds and then reinstating them appears to have done the trick. I'm now seeing all of the SSL handshake and I can access the servers.

Kind Regards

Cathy