Trouble with configuring CSM-S on cisco

Garage Irvine · ‎10-05-2011

Hello I have configured SSL-offload on CSM-S module in Router Mode(Nat Server) but seems that it works incorrectly.

I have generated certificate, uploaded it and it works fine:

ssl-proxy.csm10.slb3a.1732.la#sh ssl-proxy service CCARTSTORAGE
Service id: 1, bound_service_id: 257
Virtual IP: 10.40.109.70, port: 443 (secondary configured)
Server IP: 199.116.177.165, port: 80
rsa-general-purpose certificate trustpoint: cartstorage
  Certificate chain for new connections:
    Certificate:
       Key Label: cartstorage, 1024-bit, exportable
       Key Timestamp: 15:52:56 JPT Sep 23 2011
       Serial Number: 02
    Root CA Certificate:
       Serial Number: E0B2285358D4A371
  Certificate chain complete
Admin Status: up
Operation Status: up

 vserver CCSTORAGE-SSL
  virtual 199.116.177.165 tcp https
  vlan 522
  serverfarm CCSTORAGE-SSL
  persistent rebalance
  inservice
!
 vserver CCSTORAGE-WWW
  virtual 199.116.177.165 tcp www
  vlan 522
  serverfarm CCSTORAGE-WWW
  persistent rebalance
  inservice
!

I did everything according to this doc:

http://www.cisco.com/en/US/docs/interfaces_modules/services_modules/csms/2.1.1/configuration/guide/SSLxple.html#wp1286050

HTTP works fine.

But when I try to access our vserver via HTTPS it drops me my certificate, I'm accepting it and then the connection just drops.

I can see RST packets going from SSL-daughter card in wireshark.

I also cannot ping vserver address (199.116.177.65) from ssl-proxy.

Documentation didn't give any info about should be pingable or not

.

Seems that the problem is in routing, but I can't found out where.

What my mistake?

Please see both CSM and SSL PROXY and some useful info here:

CSM-S: http://pastebin.com/raw.php?i=5Cxvnbfv

SSL-PROXY: http://pastebin.com/raw.php?i=fb6M9qAp

Konstantin Dunaev · ‎10-06-2011

Hi,

you can start tcpdump on realservers and check if they use the correct IP/port for communication with Loadbalancer.

Garage Irvine · ‎10-08-2011

I started tcpdump on all three real servers.

When I go through http, I see that traffic on real servers:

17:32:18.944943 IP 95.79.133.64.61347 > 10.40.105.147.80: Flags [S], seq 1691755117, win 65535, options [mss 1452,nop,wscale 1,nop,nop,TS val 921369964 ecr 0,sackOK,eol], length 0
17:32:18.944990 IP 10.40.105.147.80 > 95.79.133.64.61347: Flags [S.], seq 157952838, ack 1691755118, win 14480, options [mss 1460,nop,nop,TS val 136468294 ecr 921369964,nop,wscale 7], length 0
17:32:19.228887 IP 95.79.133.64.61347 > 10.40.105.147.80: Flags [.], ack 1, win 33120, options [nop,nop,TS val 921370254 ecr 136468294], length 0
17:32:19.230578 IP 95.79.133.64.61347 > 10.40.105.147.80: Flags [P.], seq 1:332, ack 1, win 33120, options [nop,nop,TS val 921370255 ecr 136468294], length 331
17:32:19.230606 IP 10.40.105.147.80 > 95.79.133.64.61347: Flags [.], ack 332, win 122, options [nop,nop,TS val 136468323 ecr 921370255], length 0
17:32:19.230832 IP 10.40.105.147.80 > 95.79.133.64.61347: Flags [P.], seq 1:356, ack 332, win 122, options [nop,nop,TS val 136468323 ecr 921370255], length 355
17:32:19.230877 IP 10.40.105.147.80 > 95.79.133.64.61347: Flags [F.], seq 356, ack 332, win 122, options [nop,nop,TS val 136468323 ecr 921370255], length 0
17:32:19.439761 IP 95.79.133.64.61347 > 10.40.105.147.80: Flags [.], ack 356, win 32942, options [nop,nop,TS val 921370464 ecr 136468323], length 0
17:32:19.439805 IP 95.79.133.64.61347 > 10.40.105.147.80: Flags [.], ack 357, win 32942, options [nop,nop,TS val 921370464 ecr 136468323], length 0
17:32:19.440777 IP 95.79.133.64.61347 > 10.40.105.147.80: Flags [F.], seq 332, ack 357, win 33120, options [nop,nop,TS val 921370465 ecr 136468323], length 0
17:32:19.440803 IP 10.40.105.147.80 > 95.79.133.64.61347: Flags [.], ack 333, win 122, options [nop,nop,TS val 136468344 ecr 921370465], length 0

But when I try go by https, there is no any traffic on realservers at all. The requests doesn't get real servers and die somewhere on ssl-proxy or csm or between them, and I don't know how to check it.

There are also no any access-lists on those vlans on MSFC.

Garage Irvine · ‎10-19-2011

the problem is resolved now.

there were incorrectly configured secondary CSM-S ft as failover.

and aliased ip addresses on server vlans caused ip conflict.