07-11-2006 02:41 AM
I have a strange issue that is bugging the hell out of me.
We have around 5 or 6 sites that use the SSL feature of our CSS11501 that work flawlessly. The web servers the CSS forwards to are all directly connected on a subnet hanging off the CSS. I have been asked to setup a new site where by SSL termination occurs on the internet DMZ CSS but then forwards to another CSS (in clear text)that resides in our middleware DMZ (i.e: not a directly connected network). This CSS then load balances to 2 web servers. Internally going direct to the middleware DMZ CSS it works fine.
I have all the service and content rules setup as any other of our sites except the service points to the down stream CSS rather than a directly attached web server. What I am seeing is that a user makes the initial SSL connection to the VIP address and is served up the certificate but then the user then tries to make a direct HTTP connection to the CSS defined as the service address. This is a private address so will never get there.
Here is a basic topology
internet
|
|
FW----CSS with SSL (internet DMZ)
|
|
FW----CSS (mware DMZ)---web servers
Here is the config.
ssl-proxy-list ssl_accel
ssl-server 7
ssl-server 7 vip address 205.102.196.120
ssl-server 7 rsacert www-placement-cert
ssl-server 7 rsakey www-placement1
ssl-server 7 cipher rsa-with-rc4-128-md5 10.150.149.100 80
ssl-server 7 cipher rsa-with-rc4-128-sha 10.150.149.100 80
active
!************************** SERVICE **************************
service mware-css
protocol tcp
port 80
keepalive type http
keepalive frequency 60
ip address 10.150.149.100
active
service secure-transfer
ip address 2.2.2.2
keepalive type none
type redirect
no prepend-http
redirect-string "https://www.placement-services.com"
active
service ssl_accel
slot 2
type ssl-accel
keepalive type none
add ssl-proxy-list ssl_accel
active
!*************************** OWNER ***************************
owner Placement
content www_placement_http
vip address 205.102.196.120
protocol tcp
port 80
url "/*"
add service secure-transfer
active
content www_placement_ssl
protocol tcp
advanced-balance ssl
port 443
application ssl
vip address 205.102.196.120
add service ssl_accel
active
I suspect the SSL proxy list shouldn't be listing the down stream CSS but I am not sure what else I could point it to??
Thanks in advance for any assistance.
07-11-2006 05:46 PM
Simon,
See the config below. I just re-arranged your clear-back service and the ssl-proxy-list as well. What I did was I used the command urlrewrite to allow the https to http transition to be a smooth one at the 2nd CSS and used an arbitrary 10.10.10.10 ip address as VIP for the back-end service when the ssl traffic gets decrypted into clear http.
Hope this would work.
ssl-proxy-list ssl_accel
ssl-server 7
ssl-server 7 vip address 205.102.196.120
ssl-server 7 rsacert www-placement-cert
ssl-server 7 rsakey www-placement1
ssl-server 7 cipher rsa-with-rc4-128-md5 10.10.10.10 81
ssl-server 7 urlrewrite 20 placement-services.com
active
!************************** SERVICE **************************
service mware-css
protocol tcp
port 80
keepalive type http
keepalive frequency 60
ip address 10.150.149.100
active
service secure-transfer
ip address 2.2.2.2
keepalive type none
type redirect
no prepend-http
redirect-string "https://www.placement-services.com"
active
service ssl_accel
slot 2
type ssl-accel
keepalive type none
add ssl-proxy-list ssl_accel
active
!*************************** OWNER ***************************
owner Placement
content www_placement_http
vip address 205.102.196.120
protocol tcp
port 80
url "/*"
add service secure-transfer
active
content www_placement_ssl
vip address 205.102.196.120
protocol tcp
port 443
advanced-balance ssl
application ssl
add service ssl_accel
active
content clear-back-mware_CSS
vip address 10.10.10.10
protocol tcp
port 81
url "//placement-services.com/*"
add service mware-css
active
07-12-2006 12:02 AM
Thanks for your help. I am now seeing the traffic flow through the fw to the internal CSS. The certificate is being displayed instantaneously on the users PC but a blank page is being returned. Even if I change the mware-css to be one of the actual web servers thus removing the internal CSS a blank page is still displayed. If I access the internal CSS direct it works as expected so I am sure the config internally is OK. I'm getting there but it is just not 100% yet.
07-12-2006 12:27 AM
Simon,
I pressume you use single interface for the incoming and outgoing traffic between 1st FW and that Internet facing CSS. If yes, on this CSS, you need to allow Source-NAT-ing in addition to the default destination-NAT-ing.
Try adding this config below to the one that I already suggested.
group mware-css
vip address 205.102.196.120
add destination service mware-css
active
Don't forget to:
1/ configure the mware FW to allow packets with source ip 205.102.196.120.
2/ add static route on the Internet-facing-CSS to reach the mware CSS server side circuit's ip subnet.
3/ the mware CSS should have the default gateway configured on it pointing mware firewall.
Hope this would help a bit.
thanks
07-12-2006 06:00 AM
Does the config above achieve both source and destination natting? I suspect not. I have confirmed that the mware css receives traffic from the internet css and it can respond to it. for some strange reason users are still displayed a blank page. A TCPDUMP on my firewall shows communication between the internet CSS and the mware CSS one the internet CSS's actual interface IP but the mware CSS communicates on it's VIP address. is this expected behaviour? I would have thought it would be on the internet CSS VIP address??
07-12-2006 03:47 PM
The config I gave last actually should alter the default behaviour which is dest NAT-ing. Our need at this stage is to have the packets only being Source NAT-ed. My apologies if I sounded wrong earlier.
Reg. the communication between the Internet CSS and the mware CSS, Int.CSS should use its VIP on the Source Group 205.102.196.120 and the mWare CSS should use its VIP under the CR. If there is any deviation if you find just post here the mware CSS config as well.
Try doing an ftp or telnet apart from pinging from each other CSS, and make sure it works and this will tell whether the L3 is connectivity is up or not. Remember when you do the FTP/Telnet the actual circuit ip address would be used and not VIPs as I mentioned above. You might want to open FW gates before that.
thanks
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide