10-01-2009 03:20 PM
I'm terminating SSL on the CSS for a website that we want to force users to use HTTPS to get to the site. If the user uses HTTP we want the Load balancer to change it to HTTPS have the user use the HTTPS url for all queries to the site.
I've looked at a couple of ways of doing this. One method is to create a special 'service' entry which rewrites the URL. But I don't see how this can work with the normal way SSL terminated websites are configured.
is the example of that.
Alternately there's the 'ssl-server 1 urlrewrite 1 www.domain.com' command, but that seems to only cause backend webserver issued redirects to get changed from http to https. It doesn't cause the incoming request to be changed.... ?
Thanks.
Solved! Go to Solution.
10-01-2009 08:12 PM
You are correct. The IP address is bogus on the example you have provided. Your redirect service does not require an IP address in order for it to work properly.
The configuration you have posted should accomplish what you are requesting however you will need to add a new content rule:
service ssl_module
add ssl-proxy-list ssl-list1
keepalive type none
type ssl-accel
slot 2
active
service redir-https
keepalive type none
type redirect
no prepend-http
domain https://www.domain.com
active
owner domain
content http
vip address
port 80
protocol tcp
url "/*"
add service redir-https
active
content http
vip address
port 81
protocol tcp
url "/*"
add service web-service
active
content ssl
vip address
protocol tcp
port 443
add service ssl_module
advanced-balance ssl (if you want to maintain stickyness for SIDs)
application ssl (Reuse of SIDs for HTTPS connections)
active
The reason for the alternate port content rule(I just chose port 81, but any port can be used) is to allow the decrypted HTTPS connection/traffic to be handled to the webserver for processing. If you do not have the alternate port your HTTP connection will fall into a redirect loop if you have the proxy-list configuration setup to forward the decrypted traffic back to port 80. This pattern will continue and the browser will never be able to resolve content.
Redirect loop will occur with the following:
ssl-server 1 cipher all-cipher-suites
Content will be displayed correctly as the CSS can forward the decrypted traffic to an alternate port content rule for the webserver to process the connection with the following in the proxy-list:
ssl-server 1 cipher all-cipher-suites
You alternate port content rule can be used with a form of session persistence as well, ie. cookie, ARPT cookie, sticky-scrip, etc.
Hope this info clarifies everything!
- Jason
10-01-2009 06:11 PM
Creating a redirect service on your CSS should accomplish what you are requesting. Simply create and apply the redirect service to the HTTP port 80 content rule on the CSS.
There is 2 different ways of doing a redirect service on the CSS. Use either a "redirect-string" or "domain". Both of which operate differently. If you want the CSS to preserve the client's path information within the initial URL request but redirect their connection to HTTPS then a type redirect service with "domain" would suffice.
Example of a "domain" redirect service configuration:
service redirect-https
type redirect
no prepend-http
keepalive type none
domain "https://www.domain.com"
active
How the "domain" redirect will operate:
Client types the following URL:
CSS performs a 302 redirect and sends the client to the following URL:
If you do not want the CSS to preserve the path information within the client's URL and simply redirect their connection to HTTPS then a type redirect service with "redirect-string" would be your option.
Example of a "redirect-string" redirect service configuration:
service redirect-https
type redirect
no prepend-http
keepalive type none
redirect-string "https://www.domain.com"
active
Customer types the following URL:
CSS performs a 302 redirect and sends the client to the following URL:
The client's connection should remain on HTTPS unless your webservers are setup to redirect the client's connection back to HTTP when they click specific URLs/links within the site. If that is the case then you can setup a urlrewrite rule on the proxy-list to ignore any 300 series redirects given off by the webservers. The CSS will rewrite the domain to HTTPS rather then HTTP when the servers "attempt" to redirect the client's connection back to HTTP.
The following rewrite rule will ignore ALL 300 series redirects given off by the Webservers:
ssl-server 1 urlrewrite 1 *
The following rewrite rule will ignore ALL 300 series redirects given off by the Webservers for the URL "www.domain.com":
ssl-server 1 urlrewrite 1 www.domain.com
Hope this info helps!
- Jason
10-01-2009 06:16 PM
Hi,
There are 2 ways to implement this,
1.Create a service with Type Redirect and add the service to the content rule under the owner for the HTTP port as below,
service redir-https
keepalive type none
ip add 192.168.1.1
type redirect
no prepend-http
domain https://www.domain.com
active
owner domain
content http
vip address " 1.1.1.1"
protocol tcp
port 80
url "/*"
add service redir-https
active
2. The other way is to add the redirect URL directly in the content rule
owner Domain
content http
port 80
protocol tcp
vip address 1.1.1.1
url "/*"
redirect "https://www.domain.com"
active
The difference is that in the Service method only the domain portion of the URL is changed, the rest of the URL that has for example /abc/def.jsp is preserved.
In the Content Rule Method, the entire URL will be substituted with whatever is configured in the Redirect String.
Hope this answers your question.
Cheers
Siva Srinivasan
HP Enterprise Services
10-01-2009 07:36 PM
Great information from both answers, thanks a bunch.
I'd like to use the service type of redirect so as to preserve the URL, but the delima is how will that work with the SSL termination on the device?
The examples shown by the Cisco doc on the service redirect show that the IP address given in that service is a bogus one. Is that right?
Would this work?
service ssl_module
add ssl-proxy-list ssl-list1
keepalive type none
type ssl-accel
slot 2
active
service redir-https
keepalive type none
ip address
type redirect
no prepend-http
domain https://www.domain.com
active
owner domain
content http
vip address
port 80
protocol tcp
url "/*"
add service redir-https
active
content ssl
vip address
protocol tcp
port 443
add service ssl_module
active
10-01-2009 08:12 PM
You are correct. The IP address is bogus on the example you have provided. Your redirect service does not require an IP address in order for it to work properly.
The configuration you have posted should accomplish what you are requesting however you will need to add a new content rule:
service ssl_module
add ssl-proxy-list ssl-list1
keepalive type none
type ssl-accel
slot 2
active
service redir-https
keepalive type none
type redirect
no prepend-http
domain https://www.domain.com
active
owner domain
content http
vip address
port 80
protocol tcp
url "/*"
add service redir-https
active
content http
vip address
port 81
protocol tcp
url "/*"
add service web-service
active
content ssl
vip address
protocol tcp
port 443
add service ssl_module
advanced-balance ssl (if you want to maintain stickyness for SIDs)
application ssl (Reuse of SIDs for HTTPS connections)
active
The reason for the alternate port content rule(I just chose port 81, but any port can be used) is to allow the decrypted HTTPS connection/traffic to be handled to the webserver for processing. If you do not have the alternate port your HTTP connection will fall into a redirect loop if you have the proxy-list configuration setup to forward the decrypted traffic back to port 80. This pattern will continue and the browser will never be able to resolve content.
Redirect loop will occur with the following:
ssl-server 1 cipher all-cipher-suites
Content will be displayed correctly as the CSS can forward the decrypted traffic to an alternate port content rule for the webserver to process the connection with the following in the proxy-list:
ssl-server 1 cipher all-cipher-suites
You alternate port content rule can be used with a form of session persistence as well, ie. cookie, ARPT cookie, sticky-scrip, etc.
Hope this info clarifies everything!
- Jason
10-01-2009 08:33 PM
Yes I think that explains it. We use the port 80 content rule to do the redirect on incoming traffic. The port 81 content rule is used to send the traffic to the back-end webserver. Right?
So using the above config I'll need to configure the webserver to listen on port 81 to correctly handle the traffic?
10-01-2009 09:05 PM
Yes, your understanding of the communication process is correct. The HTTP port 80 content rule will redirect the client's connection; then the port 81 content rule would be used to process/handle the decrypted traffic from the client's HTTPS connection using the webserver.
Yes, you are also correct that the server must be configured to listen on the alternate port (this case 81) to correctly handle the client's traffic.
- Jason
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