Assistance requested with HTTPS Response Redirect - VMware Platform Services Controller

I tried several other configurations which I thought may work.

Here is one:

Result: no change

Note: currently using a 45-day trial license with v11.6.1. When configuration is stable, it will eventually be moved to physical F5s running 12.1.0.

Another attempt did not produce any changes in the results. Used: https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-implementations-11-4-0/21.html Section: Creating a Rewrite profile to specify URI rules

Creating a Rewrite profile to specify URI rules

To configure the BIG-IP system to perform URI translation, you create a Rewrite profile, specifying one or more URI rules that associate a client-side path with a server-side URI. You also specify whether you want the URI translation to pertain to HTTP requests, responses, or both.

On the Main tab, click Local Traffic > Profiles > Services > Rewrite. The Rewrite profile list appears.
Click Create New Profile. The Create New Profile Rewrite popup screen appears.
In the Profile Name field, type a name, such as my_rewrite_profile.
From the Parent Profile list, select rewrite.
From the Rewrite Mode list, select URI Translation.
On the left pane, click URI Rules. An empty text box appears for displaying client-server URI mappings that you specify.
Click Add.
From the Rule Type list, select Both.
In the Client URI box, type a client path, such as /sales/.
In the Server URI box, type a server URI, such as http://appserver1.siterequest.com/sales/. You must include a scheme in the server URI that you specify. An example of a scheme is http.
Click OK. This displays a mapping of the specified client path to the associated server scheme, host, and path.
Click Add again.
From the Rule Type list, select Both.
In the Client URI box, type a client path, such as /marketing/.
In the Server URI box, type a server URI, such as http://appserver2.siterequest.com/marketing/. You must include a scheme in the server URI that you specify. An example of a scheme is http.
Click OK. This displays a mapping of the specified client path to the associated server scheme, host, and path.
Click OK.

The BIG-IP system now includes two URI rules for performing URI translation on both requests and responses. For example, the host name in a request destined for http://www.siterequest.com/sales/ will be translated to http://appserver1.siterequest.com/sales/, and the host name in a request destined for https://www.siterequest.com/marketing/ will be translated to http://appserver2.siterequest.com/marketing/. A reverse translation occurs on any response.

Again, this did not produce any changes in the results. Using the web browser to go to https://psc2.company.com still results in the web browser showing https://node1.company.com.

Thoughts?

you could have a look at the proxypass irule: https://devcentral.f5.com/codeshare?sid=646

it can do more but one of the things is thing and that might make it easier then building your own from scratch.

boneyard, I can take a look at the proxypass iRule, but please note that F5 documentation states: "Important: The BIG-IP reverse proxy feature replaces the ProxyPass iRule available on the F5 Networks site https://www.f5.com/."

 

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/ltm-profiles-reference-12-1-0/2.htmlunique_312325590

 

I tried using a "rewrite" profile. No change in results. (see post above for details)

 

Thanks

 

The symptoms made me question whether or not the response traffic (from the back-end servers to the client workstations) is actually going back through the F5. If not, this would explain why the rewrite profile is not having an effect.

I am reviewing iRule "101" docs and similar items posted inn DevCentral.

Assuming the traffic flow is Client -> VIP -> Back-End-Server -> VIP - Client, it seems to me that a simple iRule applied to the HTTPS VIP with a "http" profile assigned to it should do the trick.

Here is what I have now: An iRule applied to the 443 virtual server: when HTTP_RESPONSE { HTTP::header replace Host "psc.company.com" }

Just for the heck of it, I applied this iRule to All VIPs related to this server (PSC).

I started using tools such as ssldump, tcpdump, openssl, wireshark, and cURL.

When cURL was used, I noted this in what I believe to be the HTTP_RESPONSE: So... one goes to https://psc.company.com and one gets back https://back-end-server.company.com/websso. Note that, if the SSL is working, the web browser does show "https" for the URI. I noticed that the information pulled from cURL showed "http" and NOT "https."

In any case, I would have thought the iRule with the replace statement (as per above) would have worked.

What am I missing? (keep in mind, I am new to tracking down anything web/http/https related and to iRules as well)

Thanks!

In case my post wasn't clear, despite using the simple HTTP_RESPONSE line noted above, the issue persists... going to https://psc.company.com results in the web page showing https://back-end-server.company.com/websso.

Additional updates follow.

1) A BIG THANK YOU goes to specific F5 personnel who have assisted where possible. Names withheld to protect the innocent (seriously), but you know who you are and I know you read comments - so thanks.

Note: the F5 web page is complaining about the text I am posting, so I am going to break it down bit by bit.

2) With guidance, an Access Policy Manager wizard was used to create a Access Profile, Connectivity Profile, and other behind-the-scenes configurations which I have yet to figure out. The result was that when going to https://www.company.com, the web browser retained the www.company.com instead of replacing it with node1.internal.company.com. An undesired side effect is that the F5 added a long string of text after the host name and prior to the Location (if I am getting terminology correct) itself. So, instead of seeing https://www.company.com/websso, the web browser shows something like https://www.company.com/f5-6jklaskldjklj21asdjklfjal12jklasjlkdfasjlkjasdk$$/websso. Obviously, this is still not ideal, so back to the drawing board I go.

3) It has become obvious that I need to find an authoritative informational source detailing the components (again, terminology?) available within each section of the HTTP space. For example, [HTTP::host] is apparently not a valid component of an HTTP_RESPONSE (or so said the iRule checker), while [IP::server_addr] is. However, [HTTP::host] is valid within an HTTP_REQUEST. As you can gather, it is necessary to understand all of the HTTP "parts" (such as REQUEST, RESPONSE, CLIENT_ACCEPT, and so on) and then what components (or "variables," although I believe this is a misnomer in this context) are available within each "part."

Would someone please be able to provide information (link, title, etc.) regarding such an authoritative source to explain all the "things" iRules can work with?