Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    [SOLVED] HTTP and HTTPS backends switching

    Scheduled Pinned Locked Moved Cache/Proxy
    9 Posts 2 Posters 1.7k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • U
      Ulrar
      last edited by

      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.net

      Those are configured to go to the backend-http.

      https://dev.company.net
      https://.dev.company.net
      https://
      .*.dev.company.net

      Those 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

      1 Reply Last reply Reply Quote 0
      • D
        doktornotor Banned
        last edited by

        deleted

        1 Reply Last reply Reply Quote 0
        • U
          Ulrar
          last edited by

          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).

          1 Reply Last reply Reply Quote 0
          • D
            doktornotor Banned
            last edited by

            @Ulrar:

            (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.

            1 Reply Last reply Reply Quote 0
            • U
              Ulrar
              last edited by

              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.

              http.jpg
              http.jpg_thumb
              https.jpg
              https.jpg_thumb
              backend-http.png
              backend-http.png_thumb
              backend-https.png
              backend-https.png_thumb

              1 Reply Last reply Reply Quote 0
              • D
                doktornotor Banned
                last edited by

                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"?!)

                1 Reply Last reply Reply Quote 0
                • U
                  Ulrar
                  last edited by

                  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 ?

                  1 Reply Last reply Reply Quote 0
                  • D
                    doktornotor Banned
                    last edited by

                    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.

                    1 Reply Last reply Reply Quote 0
                    • U
                      Ulrar
                      last edited by

                      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.

                      1 Reply Last reply Reply Quote 0
                      • First post
                        Last post
                      Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.