cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1923
Views
0
Helpful
3
Replies

Trouble with configuring CSM-S on cisco

Garage Irvine
Beginner
Beginner

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

3 Replies 3

Konstantin Dunaev
Enthusiast
Enthusiast

Hi,

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 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
Beginner
Beginner

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Recognize Your Peers