01-15-2007 02:03 PM
Hi all,
I have a CSM-S module in a Cat65xx system and working on my design. The MSFC is on the client side and the server and client side at the CSM should be in the same subnet (so bridge mode!?).
How can I integrate the SSL daughtercard (DC)? Can I use the DC in the same subnet/vlan? If not, which other possibility I have to use the DC in this configuration? Thanks in advance
Thomas.
01-16-2007 02:15 AM
here is a document showing how to do it with a CSM and SSL module separate, but it should work with csm-s as well.
Gilles.
01-16-2007 10:53 AM
Hi Thomas
We use CSM-S in our environment. Here is a base config which might help. We bridge for http and route to the SSL daughter card for https.
6500 CSM config
===============
vlan 10 client
description Firewalled vlan - bridge mode 10/11
ip address 10.5.1.6 255.255.255.0 alt 10.5.1.7 255.255.255.0
gateway 10.5.1.1
!
vlan 11 server
description Bridge mode 11/10
ip address 10.5.1.6 255.255.255.0 alt 10.5.1.7 255.255.255.0
!
vlan 41 server
description SSL admin vlan
ip address 10.9.1.246 255.255.255.0 alt 10.9.1.245 255.255.255.0
!
vlan 301 server
description SSL offload vlan
ip address 10.100.1.19 255.255.255.0 alt 10.100.1.20 255.255.255.0
alias 10.100.1.1 255.255.255.0
!
probe TCP tcp
interval 5
failed 10
open 4
!
serverfarm WEB-FARM01
nat server
no nat client
real 10.5.1.11 80
inservice
real 10.5.1.12 80
no inservice
probe TCP
!
serverfarm WEBSSL
nat server
no nat client
real 10.100.1.40 local
inservice
!
vserver VSSL
virtual 10.5.1.5 tcp https
serverfarm WEBSSL
persistent rebalance
inservice
!
vserver WEB01
virtual 10.5.1.5 tcp www
serverfarm WEB-FARM01
no persistent rebalance
inservice
!
SSL Daughtercard
================
ip domain name rivendell.com
!
ip ssh rsa keypair-name ssh_rivendell
!
!
ssl-proxy service sslterm
virtual ipaddr 10.100.1.40 255.255.255.0 protocol tcp port 443 secondary
server ipaddr 10.5.1.5 protocol tcp port 80
certificate rsa general-purpose trustpoint Cert-W2K
inservice
ssl-proxy vlan 41
ipaddr 10.9.1.244 255.255.255.0
gateway 10.9.1.1
admin
ssl-proxy vlan 301
ipaddr 10.100.1.21 255.255.255.0
gateway 10.100.1.1
route 10.5.1.0 255.255.255.0 gateway 10.100.1.1
!
Obviously you need certs on your SSL card. I've left vlan 41 config in there - we use this for admin of ssl DC's, they are not used for https traffic.
It works fine for us.
HTH
01-23-2007 12:57 PM
Thanks both of you for your replay. Jon, I planned exactly the same configuration like you. Last week I configured the csm and the dc in this way but got a strange result (my confs as attachments - IP changed to 1.1):
A client starts with a connect to the vserver INTER_443 with port 443. I get back the question for the correct certificate from the dc which I allow. After the confirm of the certificate the connections change from https to http and all other traffic goes via normal http traffic. Now is the question after the confirmation of the certificate why does the traffic fall back to http and not using https. Any ideas for this issue???
Jon, may I have another question: Did you ever tried to connect from one real server at the server vlan to a vserver. Should this work? I saw at other posts that this should work!? My customer has at his webservers a java app running which will connect to one of the vservers and we get no result. But I will post this in another message.
Thanks for any help or ideas to check, Thomas.
01-24-2007 12:58 AM
Hi
Your config differs from mine in a couple of ways.
1) On mine the serverfarm IP address for the SSL service matches the VIP used on the DC under the ssl-proxy service config. Yours differs - you have 1.1.147.133 on your serverfarm and 172.28.147.133 under your ssl-proxy service.
2) On mine the server IP address under the ssl-proxy service matches my http vserver WEB01. On your you have used a different vserver, SSL_CLEARTEXT from your standard http vserver INTER_80.
Not sure whether these were intended ?
Yes we did try connecting from a real server back to a vserver. We even went one further and had the same server recontact itself on a different VIP. It didn't work well for us but yes it should work, especially the simpler solution of a real talking to a vserver which points to different servers.
In the end we switched to one-arm mode, although that is often not recommened, as we had quite a few interconnections going through the CSM-S which didn't need to be load-balanced.
HTH
01-24-2007 09:06 AM
Hi, thanks for your quick answer.
Maybe I'm reading something wrong but I can't see the difference between our configs!?
Ooooo, during the reading I see my mistake. In my attachment is the failure - I didn't changed the 172.28.147.133 to 1.1.147.133 ;o) Sorry for the confusion. Think the 172.28 as 1.1 and I have the same conf like you. So that should not the problem :o(
For point 2 of your message you're right. I used another vserver "SSL_CLEARTEXT" to be more flexible and more secure (finally I plan that just the DC can connect to this vserver). This vserver is pointing to the same real servers and should work like the other vserver for http. Maybe I give a try to use the same webserver but I assume this is not the problem!? And this configuration works for you fine? Great for you - it seems that I've not this luck ;o)
01-24-2007 10:54 AM
Thomas
I can't see it making much difference either to be honest.
If i get a chance i'll try and put the config back onto our test environment and see what happens.
Are you sure that the application itself is not passing back URL's that point to the http vserver address ?
Jon
01-24-2007 01:32 PM
Jon, yep that is exactly what I'm thinking too.
I have to check with the customer. Will let you know if I find it out. Many thanks for your time,
Thomas.
01-25-2007 12:44 AM
Thomas,
if the server uses HTTP redirect because the location of the HTTP objects has been moved, then you need to translate this redirect from HTTP to HTTPS with the SSL module.
This is done with a url-rewrite function.
There are a few examples on how to do this @
Gilles.
03-20-2007 11:48 PM
Hi Gilles/Everybody,
had a problem with the SSL access via telnet as shown on the Documentation. I have created a VLAN (SVI) on the MSFC, and Created the same VLAN (server VLAN) on the CSM Module and equally on the SSL_DC all on the same subnet, with my gateway as the ip address on the MSFC, got the normal Default route on the SSL_DC automatically generated pointing to the gateway.
But from the MSFC i am able to ping the ip address on the CSM, but not able to ping the ip on the SSL_DC, have all the configs on the vty lines on the SSL_DC that are required for normal telnet but all in vain. find the configs below.
created the VLAN
on the MSFC of 6513
vlan 801
name SSL-DC_administrative
interface vlan 801
ip address 10.6.78.1 255.255.255.240
no shut
module ContentSwitchingModule 5
vlan 801 server
ip address 10.6.78.3 255.255.255.240
ssl-proxy vlan 801
ipaddr 10.6.78.5 255.255.255.240
gateway 10.6.78.1
admin
line vty 0 4
password cisco
login
privi l 15
loggin sync
enable password cisco.
03-21-2007 03:36 AM
the gateway command is for traffic hitting ssl-vip.
For management traffic [telnet,ping] you need to configure an ip route. Just like for ios.
So, try to add an 'ip route 0.0.0.0 0.0.0.0 10.6.78.1' on the SSL-DC and see if it works.
Gilles.
03-21-2007 04:36 AM
Gilles,
thank you for your response, the SSL-DC by itself added the "route" command ro the configuration. i.e. route 0.0.0.0 0.0.0.0 10.6.78.1
or did you mean i should add "ip route" just as in the IOS ?
all i need is telne/ping access to the SSL-DC.
TIA
hash
03-21-2007 05:37 AM
You need to add the following on your SSL DC.
ip route 0.0.0.0 0.0.0.0 10.6.78.1
HTH
Jon
03-21-2007 06:08 AM
thank you Jon,
Will try that and get back to you. thought there was no need sine the SSL DC adds the "route 0.0.0.0 0.0.0.0 10.6.78.1" by itself. as shown on this link
Thanks you for your help.
Hash
03-21-2007 06:37 AM
route and 'ip route' are different.
There is 2 routing table on this box.
The one for managmenet traffic like telnet/ping requires the 'ip route' command
Gilles.
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: