Showing results for 
Search instead for 
Did you mean: 

Trouble with configuring CSM-S on cisco

Garage Irvine
Level 1
Level 1

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 service CCARTSTORAGE
Service id: 1, bound_service_id: 257
Virtual IP:, port: 443 (secondary configured)
Server IP:, port: 80
rsa-general-purpose certificate trustpoint: cartstorage
  Certificate chain for new connections:
       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

  virtual tcp https
  vlan 522
  serverfarm CCSTORAGE-SSL
  persistent rebalance
  virtual tcp www
  vlan 522
  serverfarm CCSTORAGE-WWW
  persistent rebalance

I did everything according to this doc:

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 ( 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:



3 Replies 3


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

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 > 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 > 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 > Flags [.], ack 1, win 33120, options [nop,nop,TS val 921370254 ecr 136468294], length 0

17:32:19.230578 IP > Flags [P.], seq 1:332, ack 1, win 33120, options [nop,nop,TS val 921370255 ecr 136468294], length 331

17:32:19.230606 IP > Flags [.], ack 332, win 122, options [nop,nop,TS val 136468323 ecr 921370255], length 0

17:32:19.230832 IP > Flags [P.], seq 1:356, ack 332, win 122, options [nop,nop,TS val 136468323 ecr 921370255], length 355

17:32:19.230877 IP > Flags [F.], seq 356, ack 332, win 122, options [nop,nop,TS val 136468323 ecr 921370255], length 0

17:32:19.439761 IP > Flags [.], ack 356, win 32942, options [nop,nop,TS val 921370464 ecr 136468323], length 0

17:32:19.439805 IP > Flags [.], ack 357, win 32942, options [nop,nop,TS val 921370464 ecr 136468323], length 0

17:32:19.440777 IP > Flags [F.], seq 332, ack 357, win 33120, options [nop,nop,TS val 921370465 ecr 136468323], length 0

17:32:19.440803 IP > 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
Level 1
Level 1

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.