LB HTTPS Reverse Proxy

That looks about right. This assumes that the client isn't making POST requests to the URIs with the template parameter. If they were, they'd get redirected and make a GET request to the HTTPS URI from the redirect.

Here are a couple of edits for the iRule:

when HTTP_REQUEST {
        if {[class match -- [URI::query [HTTP::uri] template] equals template_dg]}{
                HTTP::redirect "https://[HTTP::host][HTTP::uri]"
        }
}

Aaron

Sorry I missed a couple of your questions:

 

 

Would I need a clientSSL profile (certificate & key)?

 

If the app only handles HTTP and you want LTM to offload SSL for the HTTPS virtual server you'd need a client SSL profile on the HTTPS virtual server.

 

 

What kind of certificate would I need?

 

You'd need a CA signed certificate valid for the hostname(s) the client would use to connect to the HTTPS virtual server. The format should be PEM (or you can convert a PFX).

 

 

Aaron

Thanks so much Aaron. This just got a little more complicated.

 

 

New scenario:

 

So requests are NOW going to come in on HTTP instead of HTTPS. My plan is to redirect HTTP traffic BASED on the three URL's above to an existing HTTPS VIP. (So the client can see that their request is HTTPS), then I hope to send traffic back to the server on HTTP, again if one of the three URL's above are matched. However the existing HTTPS VIP has a serverside SSL profile, that cannot be removed.

 

 

My question: is there any way to selectively disable the serverside profile from the VIP based on an iRule matching one of the three URI's? :)

 

 

If I can selectively disable the serverside profile, I can avoid creating 24+ new HTTPS VIPs.

Hi,

in principle, you could disable the serverside profile with

 SSL::disable [clientside | serverside]

https://devcentral.f5.com/wiki/iRules.ssl__disable.ashx

This disables ssl per connection, not per request, which would not be desired and in your case would probably cause failures.

If you really want to get away with the same vs, you could select a different pool based on the request, and then disable serverssl for that virtual.

If you would create 24 new HTTPS VIPS, would you not need to have new Virtual IPs as well, if you would stay on standard ports ? And then, would you not need new certs, if you are on a public DNS infrastructure ?

Christian

Our infrastructure masks several redundant LTM's. So using the existing number of HTTPS VIPS we have for this domain, would yes, avoid new IPs, new certs, etc.

 

 

----

 

Client HTTP --> LTM HTTP VIP Redirect to HTTPS VIP--> HTTPS VIP 'SSL::disable serverside ' based on iRule --> sending HTTP to backend server

 

----

 

I'm a little concerned about the return traffic though.

 

 

Perhaps I'm thinking this over to hard, but wouldn't this work?

 

 

when HTTP_REQUEST {

 

if {[class match -- [URI::query [HTTP::uri] template] equals template_dg]}{

 

SSL::disable serverside

 

HTTP::redirect "https://[HTTP::host][HTTP::uri]"

 

}

 

shouldn't SSL::disable serverside be in HTTPS' irule (rather than in HTTP's irule)?

@Nitass - the iRule will be applied to an HTTPS VIP

 

 

"--> HTTPS VIP 'SSL::disable serverside ' based on iRule"

 

 

Thanks guys! - I'll give this a run

@Nitass - the iRule will be applied to an HTTPS VIP

 

 

"--> HTTPS VIP 'SSL::disable serverside ' based on iRule"

 

 

Thanks guys! - I'll give this a run

@Nitass - the iRule will be applied to an HTTPS VIP

 

 

"--> HTTPS VIP 'SSL::disable serverside ' based on iRule" if it is applied to HTTPS VS, why do you put HTTP::redirect command (HTTP::redirect "https://[HTTP::host][HTTP::uri]" ) there??

ahhh. I missed that - thank you!

 

 

Corrections below:

 

 

HTTP VIP:

 

 

when HTTP_REQUEST {

 

if {[class match -- [URI::query [HTTP::uri] template] equals template_dg]}{

 

HTTP::redirect "https://[HTTP::host][HTTP::uri]"

 

}

 

 

 

HTTPS VIP:

 

 

when HTTP_REQUEST {

 

if {[class match -- [URI::query [HTTP::uri] template] equals template_dg]}{

 

SSL::disable serverside

 

}