[SOLVED] HTTP and HTTPS backends switching
-
Hi,
We have a backend server accessible both in HTTP and HTTPS.
Some apps are hosted on it, and need to be available on both protocols.So we have two entries in "mapping" :
http://dev.company.net
http://.dev.company.net
http://.*.dev.company.netThose are configured to go to the backend-http.
https://dev.company.net
https://.dev.company.net
https://.*.dev.company.netThose are configured to go to the backend-https.
It's the same server, just with https or not.The problem is, when accessing http://test.something.company.net/test.php for example, the HTTPS header is blinking on and off at each refresh.
It looks like http / https aren't actually used to do the matching, and it's matching the rules one after another.
Is there a way to correct that ? It doesn't actually redirect the visitor to HTTPS, it's transparent (guess only the pfsense –> backend is blinking between http and https), but since the app has HTTPS = on it's generating https links to the resources, and that's causing all sorts of problems.
Currently the developers are using the VPN to bypass the pfsense and access the backend directly, not ideal and not applicable to the clients who sometimes needs to access those URLs.Thanks
-
deleted
-
I don't want to redirect it, I want the way the visitor access the URL to be kept.
Meaning if I access http://dev.company.net I want to go to http://dev.company.net and
if I access https://dev.company.net I want to go to https://dev.company.net.Currently accessing http://dev.company.net goes to either http://dev.company.net or
https://dev.company.net on the backend, and that's completely transparent for the visitor,
who never gets redirected (the address bar always stays on http, which is fine).
-
(the address bar always stays on http, which is fine).
So how's that fine when that's NOT what you want? Show us what you have configured where, cannot make sense of it.
-
It is what I want, my problem is between the pfsense and the backend.
Here are the configs, I had to hide the domain name, but there's the exact same thing behind the black everywhere.
The visitor's side seems completely fine, you access using http you stay on http, you access using https you stay on https.
The problem is the backend gets the requests sometimes on http, sometimes on https for no apparent reason.
If you access using http, the backend should see the requests on it's port 80, not 443. And if you access using https, it should
see the requests on port 443, not 80. Currently, the first request will go on 443, the second on 80, the third on 443, the fourth on 80 …Looks to me like the match rules in the first two screens aren't actually using the http / https to differentiate the requests.
-
Uhm… Next time, it'd help to mention that you are using Squid. Outta here. In case you'd like to switch to haproxy for the purpose, chime back in.
(As a wild guess, why are both HTTP and HTTP backends - "peer mappings" - named "workspaces"?!)
-
I don't understand, is there an option ?
I'd clearly rather use haproxy, just didn't know that was possible in pfsense. Or has squid been replaced in a recent update ?
I've just followed the doc to set up a reverse proxy last year.They have the same name because they are matching the same URL to the same backend. You think the name might be why it's acting weird ?
-
They have the same name because they are matching the same URL to the same backend
What same backend? You told us you have TWO separate backends, one for HTTP and the other for HTTPS. I was pointing to the fact that you have both HTTP and HTTPS "peer mappings" named the same. Have you tried renaming of one those?
As for haproxy, yes of course it's possible, and can do zillion more things that Squid cannot.
-
Looks like the problem was indeed the name.
Well thanks, didn't think that could be it, but I suppose the name isn't just for clarity, it must be used in the conf !I'll probably replace all of this with haproxy soon anyway, but at least for now it's working.