Jump to content
Welcome to our new Citrix community!

Prestashop behind a SSL Load Balancer: How to configure?


resyrt erwtret

Recommended Posts

Hello

 

I have a Prestashop behind a SSL Load Balancer and even though it can be access, there is two issues:

 

1: The links go to HTTP

2: It does to the internal IP instead of the public IP (I setup a NAT on my firewall)

 

I should change all the links on the page from http://127.1.1.1 to (example) https://1.2.3.4

 

How can I do this? Do I need a rewrite policy? Responder? etc.

 

Thank you

Link to comment
Share on other sites

Is your load balancing set up as SSL (vserver) to HTTP (services) or end-to-end SSL where both vserver and services are SSL. 

If the former, while you can also use url transform to fix, it might be worth trying to make it use SSL services and see if it responds based on the protocol it receives.

If the latter and the website is still sending HTTP content in responses to https requests, URL Transform is usually the best way to rewrite links in body content comprehensively.

 

Rewrite and/or responder can fix different aspects of this too; but URL transform might be most comprehensive for this particular scenario if just switching to ssl services doesn't resolve the problem.

 

There are some examples of URL Transformation here:  https://discussions.citrix.com/topic/388909-url-transform-to-another-url-but-keep-orginial/

 

Link to comment
Share on other sites

16 hours ago, Rhonda Rowland1709152125 said:

Is your load balancing set up as SSL (vserver) to HTTP (services) or end-to-end SSL where both vserver and services are SSL. 

If the former, while you can also use url transform to fix, it might be worth trying to make it use SSL services and see if it responds based on the protocol it receives.

If the latter and the website is still sending HTTP content in responses to https requests, URL Transform is usually the best way to rewrite links in body content comprehensively.

 

Rewrite and/or responder can fix different aspects of this too; but URL transform might be most comprehensive for this particular scenario if just switching to ssl services doesn't resolve the problem.

 

There are some examples of URL Transformation here:  https://discussions.citrix.com/topic/388909-url-transform-to-another-url-but-keep-orginial/

 

 

The vServer is SSL but the service is HTTP.

 

To make it clearer:

My vServer is https://1.2.3.4 but my internal is http://127.0.0.1 (obviously these IPs are all fake)

 

I attempted rewrite/responder but just cannot get it to work.

 

Never tried URL transform.

Link to comment
Share on other sites

So, with the backend being HTTP, the website is inserting HTTP into  URLs its returning.  You can share what you tried and we can troubleshoot.  If the website is also using absolute URLs it may also be returning the wrong hostname to the client.

 

So more details of the exact URLs you are getting client side would help.

 

If the URLs are relative (path only) or absolute but still contain HTTP://<lb fqdn> and https://<lb fqdn>.

You can use a responder policy BUT you need to have something listening on http:80 to catch the request for the redirect to work.

Or you can use response rewrites to rewrite as they return to client.

 

If the URLs returned to client with the backend fqdn, then rewrite or URL Transform is the only way to go.

 

For a simple redirects from http to https with no hostname change required, you can use the "redirect URL method"

1a) You can set either an HTTP vserver on LB VIP:HTTP:80 in a down state, no services and set the lb vserver "protection method > redirect url" to https://<lb fqdn>  and no trailing slash. any request to http://<lb fqdn><with or without path/query> will be caught on this vserver and because its down will redirect to https:<lb fqdn><whatever path was in first request is tacked on here>  

1b) You can set the http:80 listener directly on  the SSL lb vserver.  Under the "basic setting" in the GUI expand the "more" section on your current lb vserver of type SSL.  Set redirect port to 80 and redirect URL to https://<lbfqdn> again without a final trailing slash. Does same thing as 1a and still consumes the VIP:HTTP:80 port but only to redirect traffic to new desitnation.

 

2) A responder policy.

Usually redirects apply to an UP lb vserver on VIP:HTTP:80 so you point it to a  fake backend service, disable monitoring (uncheck "health monitoring") and then you can bind the responder policy to it. Will still only work for client requests going to http://<lb fqdn>  and not if the requests contain the backend server.

 

Responder Action: REDIRECT

With expression:  "https://<lb fqdn>" + http.req.url.path_and_query

Responder Policy: with expression:  http.req.is_valid  

And BIND to the HTTP lb vserver used to send to ssl on this VIP (do not bind to the SSL vserver).

 

3) rewrites and Url transforms.

I don't have time for either right now (but can help after work, if you don't have an answer yet):

Here's an additional REWRITE replace_all example to replace http:// to https:// in links in body content BUT it doesn't adjust the FQDN yet; but it can be modified.

https://discussions.citrix.com/topic/417246-classic-to-advance-policy-conversion/#comment-2093966

 

Is there any requirement to change request time URLs being sent to the backend server or just the response URLS returned in the body.

 

Some additional context:

Usually URL Transform is used when you need the client to lb and lb to client to be a public VIP or pattern and the lb to server/server to lb backend changes hostname or pattern.

For just the HTTPS and hostname adjustment this should be easier, but variations in the type of responses and requests you are seeing will affect the best way to handle this.

 

So its good to define we have these valid requests from client to lb vserver, and they need to be same or different from adc to backend server.

Then in the response from server to adc, the links in body are in this one or mutiple formats that we then need to make look like this other format when it goes ADC to client.


IF its just the scenario http://backendfqdn needing to go to https://lbfqdn, then a response time rewrite with the replace_all action will likely work. 

If there are more variances, then URL transform might be preferred.

 

 

 

 

Link to comment
Share on other sites

Finally had some free time for the response rewrite examples.

Example 1:  Replaces links in BODY content to http://oldfqdn.demo.net<anypathorquery> (backend fqdn and http) to https://newfqdn.public.com  (public fqdn and https)

add rewrite action rw_res_rwbody_http_to_https replace_all "http.RES.body(9999999)" "\"https://newfqdn.public.com\"" -search "text(\"http://oldfqdn.demo.net\")"
add rewrite policy rw_pol_rwbody_http_to_https "http.RES.BODY(9999999).set_text_mode(ignorecase).CONTAINS(\"http://oldfqdn.demo.net\")" rw_res_rwbody_http_to_https
 

Example 2:  Replaces links in RES Location header:

add rewrite action rw_res_rwhdr_http_to_https replace_all "http.RES.HEADER(\"Location\")" "\"https://newfqdn.public.com\"" -search "text(\"http://oldfqdn.demo.net\")"
add rewrite policy rw_pol_rwhdr_http_to_https "http.RES.HEADER(\"Location\").SET_TEXT_MODE(ignorecase).CONTAINS(\"http://oldfqdn.demo.net\")" rw_res_rwhdr_http_to_https
 

 

Note: if you have a variety of http:// vs. https:// with different fqdns, this may need adjustment.  Likely Redirects (301 and 302 responses) will only need the rewrite in policy 2 and 200 OK responses will only need the policy 1 rewrite.

 

You can bind policies to the lb vserver RESPONSE HTTP flow.  You can set the goto value to NEXT so multiple rewrites can apply for convenience.

 

 

If you need to modify both URLS sent by client to the backend server AND the links in body content returned by the backend server to the client, then URL transform would be preferred. But if it is just the response from the backend server need to be changed for specific references to http://<oldfqdn><anypath and query> to https://<publicfqdn><anypath and query> then this may work for you.

Link to comment
Share on other sites

On 10/23/2022 at 12:14 AM, Rhonda Rowland1709152125 said:

Finally had some free time for the response rewrite examples.

Example 1:  Replaces links in BODY content to http://oldfqdn.demo.net<anypathorquery> (backend fqdn and http) to https://newfqdn.public.com  (public fqdn and https)

add rewrite action rw_res_rwbody_http_to_https replace_all "http.RES.body(9999999)" "\"https://newfqdn.public.com\"" -search "text(\"http://oldfqdn.demo.net\")"
add rewrite policy rw_pol_rwbody_http_to_https "http.RES.BODY(9999999).set_text_mode(ignorecase).CONTAINS(\"http://oldfqdn.demo.net\")" rw_res_rwbody_http_to_https
 

Example 2:  Replaces links in RES Location header:

add rewrite action rw_res_rwhdr_http_to_https replace_all "http.RES.HEADER(\"Location\")" "\"https://newfqdn.public.com\"" -search "text(\"http://oldfqdn.demo.net\")"
add rewrite policy rw_pol_rwhdr_http_to_https "http.RES.HEADER(\"Location\").SET_TEXT_MODE(ignorecase).CONTAINS(\"http://oldfqdn.demo.net\")" rw_res_rwhdr_http_to_https
 

 

Note: if you have a variety of http:// vs. https:// with different fqdns, this may need adjustment.  Likely Redirects (301 and 302 responses) will only need the rewrite in policy 2 and 200 OK responses will only need the policy 1 rewrite.

 

You can bind policies to the lb vserver RESPONSE HTTP flow.  You can set the goto value to NEXT so multiple rewrites can apply for convenience.

 

 

If you need to modify both URLS sent by client to the backend server AND the links in body content returned by the backend server to the client, then URL transform would be preferred. But if it is just the response from the backend server need to be changed for specific references to http://<oldfqdn><anypath and query> to https://<publicfqdn><anypath and query> then this may work for you.

 

I believe this is what I need because the links inside the page itself are what is giving issues....give me a minute to implement it....

 

Thanks

Link to comment
Share on other sites

OK, so the page is loading "better" but there is content that is failing. I believe additional rewrite policies are needed:

 

This is the error the browser is giving me (again fake IPs)

 

Mixed Content: The page at 'https://newfqdn.public.com/' was loaded over HTTPS, but requested an insecure script 'http://127.0.0.1/wp-includes/js/wp-emoji-release.min.js?ver=6.0.3'. This request has been blocked; the content must be served over HTTPS.

 

The rest of the BODY content is working OK ? so thats a good sign.

 

How could I fix this?

Link to comment
Share on other sites

Sorry had a lot of work stuff this week. There may be  couple of options.

The web sites not actually spitting out <127.0.0.1> is it? That was just a place holder, right?

We need to understand the URLs the site is using from a pattern standpoint to know what to fix and how best to do so. There's one other setting that may help. I'll try to respond this evening.

Link to comment
Share on other sites

  • 2 weeks later...

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...