07-06-2009 09:25 AM
I currently have a VIP representing one server farm that contains two http servers:-
class-map match-all VIP-HTTP-xxxxx.co.uk
2 match virtual-address 10.79.18.10 tcp eq www
class-map match-all VIP-SSL-xxxxx.co.uk
2 match virtual-address 10.79.18.10 tcp eq https
I have port 80 and 443 open on the VIP and SSL termination performed on the ACE (both http servers are the same and configured for default load balancing behaviour - I've also specified port 80 for ACE to server traffic). Having 80 and 443 on the same VIP (meaning the site can be accessed via one NAT'd external IP) came from a request from the business so the site can have one domain.
The majority of the http server(s) web content is standard http but there is a specific sub-directory of interactive forms that requires https termination.
I have a couple of queries with regards to URL re-writes:-
1) Is the SSL URL re-write functionality limited to just the host part of the URL or can the ACE enforce https for specific sub-directories, i.e. can the ACE intercept and re-write a URL if a user tries to go to a particular https page/directory using http (by just deleting the s from the URL within their browser)? A possible example being:-
ssl url rewrite location "www\.cisco\.com\secure-forms"
2) Can the ACE re-direct users back to a standard http page if they try to 'secure' their session by changing http to https within their browser (basically the opposite of the above).
Basically as I have 80 and 443 on the same VIP I'm interested in the best practice methods of enforcing http and https content segregation using just the ACE (as opposed to having Apache doing the re-writes, etc).
Web services functionality (in terms of SSL and URL re-writes) has traditionally fallen within the domain of a dedicated web development team (who use Apache, Tomcat, etc.) but the introduction of the ACE as a load balancing appliance that is primarily managed by the networks team but with functionality that crosses traditional team boundaries has resulted in lots of questions from web development around what functionality can be moved from Apache, etc. and onto the ACE?
Any advice or personal experiences would be gratefully received.
Thanks
Matthew
07-07-2009 04:19 AM
Matthew,
the rewrite is only a function to be used when your server sends an HTTP redirect.
What you actually need to do is create a L7 URL class-map to catch the traffic to be encrypted.
ie:
class-map type http loadbalance SecureUrl
match http url /secure.*
Then create a redirect rule
rserver redirect HTTP-REDIRECT
webhost-redirection https://x.x.x.x/%p 302
inservice
serverfarm redirect SF_REDIRECT
rserver HTTP-REDIRECT
inservice
And use this redirect serverfarm with the class-map in your policy-map
ie:
policy type http loadbalance first LB
class SecureUrl
serverfarm SF_REDIRECT
class class-default
serverfarm ....
Obviously, you will need a different policy for the decrypted traffic to avoid entering a redirect loop.
Gilles.
07-07-2009 08:25 AM
Gilles,
Thanks for your reply, its made things much clearer.
Whilst I can now see how to catch the traffic that needs to be encrypted I'm still not entirely sure about how to catch the traffic that needs to be decrypted, i.e. the correct regular expression string to catch https requests to any URL that is NOT âexamplewebsite.com/secureformsâ (so I can then perform a standard http re-direct back to the un-encrypted page)?
Is it even possible to just match https requests or would I effectively be catching and re-directing every http request regardless of whether it was incorrectly submitted as https?
Thanks
Matthew
07-07-2009 11:47 PM
If you want to redirect back to http, you can do the same.
For your decrypted traffic use a new policy.
policy type http loadbalance first decrypted
class L7URL
serverfarm backend-web
class class-default
serverfarm Redirect2HTTP
So, whatever matches /secure is loadbalanced and the rest is redirected to HTTP.
Gilles.
07-17-2009 03:51 AM
Back again!
Could someone possibly cast their eye over the following config?
The only bit I'm not sure on (syntactically and whether it can even be done on the ACE) is how to specify a DO NOT match regular expression, i.e. how to capture https URLs that do not match my secure pages so I can re-direct the request back to the normal http URL (class-map type http loadbalance Non-Secure_Pages). What I'd like to avoid is re-directing requests that don't need to be, i.e. re-directing all requests that don't match /secure back to http when the majority will be correctly going to a normal http URL :-
rserver host server1
description *** HTTP server 1 ***
ip address 10.100.194.2
inservice
rserver host server2
description *** HTTP server 2 ***
ip address 10.100.194.3
inservice
rserver redirect REDIRECT_TO_HTTPS
webhost-redirection https://www.website.co.uk/%p 302
inservice
rserver redirect REDIRECT_TO_HTTP
webhost-redirection http://www.website.co.uk/%p 302
inservice
class-map type http loadbalance Secure_Pages
match http url /secure.*
class-map type http loadbalance Non-Secure_Pages
*** DO NOT *** match http url /secure.*
class-map match-all VIP-HTTP-website.co.uk
2 match virtual-address 10.79.18.10 tcp eq www
class-map match-all VIP-SSL-website.co.uk
2 match virtual-address 10.79.18.10 tcp eq https
policy-map type loadbalance first-match VIP-LB-HTTP-website.co.uk
class Secure_Pages
serverfarm REDIRECT_TO_HTTPS
class class-default
serverfarm serverfarm-website.co.uk
policy-map type loadbalance first-match VIP-LB-SSL-website.co.uk
class Non-Secure_Pages
serverfarm REDIRECT_TO_HTTP
class class-default
serverfarm serverfarm-website.co.uk
serverfarm host serverfarm-website.co.uk
failaction purge
rserver server1 80
probe PING_SERVER
probe http-website.co.uk
inservice
rserver server2 80
probe PING_SERVER
probe http-website.co.uk
inservice
serverfarm redirect REDIRECT_TO_HTTPS
rserver REDIRECT_TO_HTTPS
inservice
serverfarm redirect REDIRECT_TO_HTTP
rserver REDIRECT_TO_HTTP
inservice
many thanks
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: