CSS (or ACE 4710) redirect https to http

[sez sharp]

Hi,

This topic has come up in the past but have not seen a clear proper answer

For a CSS with a SSL module (performing SSL termination) - is it possible to impliment a redirect on https URL to send to equivalent http URL

   Client  >   https://www.site.com/   >   CSS

   Client  <  302 redirect to  http://www.site.com/  <   CSS

If my understanding is correct, the CSS will do SSL termination and then use an http content rule on the resultant http stream as it is recursively handled by the CSS ?

This would mean that the SSL module has no way of seeing/acting on layer 5 and above data (i.e. picking up on a specific URL) and can not itself issue a redirect - i.e. you could not associate a redirect statement or service with the following ssl content rule ?

  content HTTPS_VIP

    vip address 1.1.1.1

    protocol tcp

    port 443

    add service SSL_MODULE

    active

The CSS would instead rely on a http content rule to impliment a redirect - i.e. you would have to associate a redirect statement or service to the following http content rule instead?

  content HTTP_VIP

    vip address 1.1.1.1

    protocol tcp

    port 80

    url "/"

    active

But if the CSS is already handling traffic for existing http://www.site.com/  traffic that is going to cause a loop when a client goes direct to

http://www.site.com/

I realise the requirment is uncommon / a bit convoluted, its one of those don't ask type scenarios - aimed at achieving a specific requirement....

Would the ACE 4710 be able to handle such a scenario any differently ?

TIA,

Sez

[Daniel Arrondo Ostiz]

Hi Sez,

As you mentioned, the CSS will first decrypt the traffic and then forward it to a HTTP content rule for further processing. It would be on this rule that the redirection is configured.

The loop you talked about would only happen if the rule to which the SSL module is sending the traffic is the same one that the clients will hit afterwards. The easy solution to this issue would be setting the redirection content rule on a different port. This way, the traffic flow would be:

• Content rule on port 443 configured for SSL termination, sending the traffic to port 81 (or any other number)
• Content rule on port 81, doing the redirection to port 80
• Content rule on port 80, doing the load-balancing.

To answer your other question, on ACE, both the SSL termination and the L7 processing are associated to the same class-map, so you would just need two classes:

• VIP on port 443 doing the SSL termination and redirection to port 80
• VIP on port 80 doing load-balancing.

I hope this helps

Daniel

[sez sharp]

Hi Daniel,

Thanks for the quick answer

My challenge is that the site already handles http and https and needs to continue to do so, an https to http redirect required only on the root URL but normal https on content deep down.

Case 1 - redirect https>http root url

Client  >   https://www.site.com/   >   CSS

Client  <  302 redirect to  http://www.site.com/  <   CSS

Case 2 - normal https

Client  >   https://www.site.com/somewhere/deeper/    >   CSS

Client  <   response traffic from https://www.site.com/somewhere/deeper/   <   CSS

Case 3 - normal http

Client  >   http://www.site.com/*    >   CSS

Client  <   response traffic from http://www.site.com/*  <   CSS

With common site VIP and ssl-proxy-list entry pointing traffic to port 81 - all  terminated ssl traffic for this site will forward to destination port 81 (i.e. at this stage can not groom traffic based on url)

This gives opportunity to have port 81 content rule to give http rediirect back to client on Case 1 traffic for specific https url

But would then also have to have port 81 content rule to forward all other "normal" traffic to port 80 to allow css to lb across back ends i.e. would be another recursive spin around css to pick up the port 80 content rules. Is that possible (service remapping) ?

thanks again,

Sez

[Daniel Arrondo Ostiz]

Hi Sez,

Your requirements are getting more and more complicated, but it's still possible to achieve.

For this scenario, you would need 4 different content rules:

1. Content rule on port 443 --> SSL termination, sending traffic to port 81
2. Content rule on port 81 and specific URLs strings --> Load-balancing (specific URLs requested over SSL, if you require this to be encrypted in the backend, you can also perform SSL initiation)
3. Content rule on port 81 and all URLs --> Redirection to to port 80 for root URL requested over SSL
4. Content rule on port 80 and all URLs --> Load-balancing for redirected traffic or initiated over HTTP

I hope this helps

Daniel

[sez sharp]

Hi Daniel,

Yep the devil is always in the detail!

Beleive me me I would prefer not to go through with this but am getting forced down this route as the 'least worst option'

The bit I am mentaly stuck on is 2)

The current set up uses just termination so backend channel is currently http over port 80

Content rule 2) would LB http traffic to backends over port 81 in addition to port 80 traffic from rule 4) ?

Meaning backends would have to listen on port 81 as well ?

Or is there a method for rule 2) to point traffic to port 80 - either to directly from that rule to LB http traffic to backends over port 80 or recursively via rule 4) ?

Thanks again,

Sez

[Daniel Arrondo Ostiz]

Hi Sez,

When you define a service on CSS, you can also specifiy a port for it, which may be different from the one configured on the content rule.

In this case, you would just need to define all the services as port 80 to have all the backend traffic sent to it, regardless of whether the content rule is listening to port 80 or 81.

Daniel

[sez sharp]

Almost there... relating it to a dummy config below to make sure I'm on same page

So specifying explicit port number (80) under service config means that even if service added to content rule handling port 81 from SSL module output, the resultant traffic heading towards back ends will be over tcp port 80 ?

TIA,

Sez

! # Content rule on VIP port 443 --> SSL termination, sending traffic to port 81

! # Content rule on port 81 and root URL --> Redirection to http for root URL requested over https

content HTTP_81_ROOT_VIP

    vip address 1.1.1.1

    protocol tcp

    port 81

    url "/index.html"

    redirect http://www.site.com/   ! # or add redirect service

    active

! # Content rule on port 81 and all other URLs --> LB all other URL's requested over https

content HTTP_81_WILD_VIP

    vip address 1.1.1.1

    protocol tcp

    port 81

    url "/*"

    add service SVR_1

    add service SVR_2

    active

! # Content rule on port 80 for all URLs --> LB all URL's requested over http

content HTTP_80_VIP

    vip address 1.1.1.1

    protocol tcp

    port 80

    url "/*"

    add service SVR_1

    add service SVR_2

    active

! # Explicitly specifying the port on service (rather than default 'any') means all traffic to backend will go over port 80 ?

service SVR_1

  ip address 10.10.10.101

  port 80

  active

service SVR_2

  ip address 10.10.10.102

  port 80

  active

[Daniel Arrondo Ostiz]

Hi Sez,

With your configuration, only the URL "http://www.site.com:81/index.html" would match the HTTP_81_ROOT_VIP content rule, if someone accesses "http://www.site.com:81" (which is what you first mentioned), it would match

HTTP_81_WILD_VIP instead.

Instead, I would suggest using a configuration like the following:

header-field-group not_root_url

  header-field not_root_url request-line not-equal "/"

  header-field not_root_index request-line not-equal "/index.html"

content HTTP_81_ROOT_VIP

    vip address 1.1.1.1

    protocol tcp

    port 81

    url "/*"

    redirect http://www.site.com/   ! # or add redirect service

    active

content HTTP_81_WILD_VIP

    vip address 1.1.1.1

    protocol tcp

    port 81

    url "/*"

    add service SVR_1

    add service SVR_2

    header-field-rule not_root_url

    active

content HTTP_80_VIP

    vip address 1.1.1.1

    protocol tcp

    port 80

    url "/*"

    add service SVR_1

    add service SVR_2

    active

For more information on how the header groups are working, check the link below

http://www.cisco.com/en/US/docs/app_ntwk_services/data_center_app_services/css11500series/v8.20/configuration/content_lb/guide/HHead.html

This configuration should be working fine, but I have to admit that I haven't tested it so make sure to test it before putting it into production.

Daniel