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

    SSL certs handling and HAproxy

    General pfSense Questions
    3
    136
    25.2k
    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.
    • L
      lewis @stephenw10
      last edited by

      @stephenw10

      That was a previous post, I've moved on since. I was trying all kinds of things, NAT and just rules.
      My last comment explains where I'm at now and yes, I'm trying to get this working direct to the web server first to remove complexities.
      Varnish was also getting https connections based on the last comment.

      1 Reply Last reply Reply Quote 0
      • stephenw10S
        stephenw10 Netgate Administrator
        last edited by

        Ok so the backend server can now use http? Nothing there is hardcoded to use https?

        It should still work with https.

        L 1 Reply Last reply Reply Quote 0
        • L
          lewis @stephenw10
          last edited by lewis

          @stephenw10
          So the setup is fairly simple right now.
          Using a rule with the vip and it's set to https.
          Then haproxy is in play but no varnish. The haproxy should be sending to the web server using http.
          On the front end, all described above.
          On the back end, all described above.

          The really weird thing is that I have the back end up to use HTTP for the health check but as shown above, the connections to the server are https.
          Why and how could that even happen? The web server is absolutely responding to http requests as well but none come from haproxy.

          11:07:21.958831 ens18 In  IP _gateway.14123 > r9ty01.phx.loc.https: Flags [S], seq 1069863897, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 1387418 ecr 0], length 0
          11:07:21.959032 ens18 Out IP r9ty01.phx.loc.https > _gateway.14123: Flags [S.], seq 3639861567, ack 1069863898, win 65160, options [mss 1460,sackOK,TS val 2268769424 ecr 1387418,nop,wscale 7], length 0
          
          
          1 Reply Last reply Reply Quote 0
          • L
            lewis
            last edited by lewis

            BTW it cannot work with https because the server is now using a self signed cert, ACME is taking care of the cert.

            1 Reply Last reply Reply Quote 0
            • stephenw10S
              stephenw10 Netgate Administrator
              last edited by

              That capture shows a simple TCP SYN / SYN-ACK that happens to be on port 443. It's not an actual http or ssl check. How is the backend actually configured?

              There's no reason HAProxy can't connect to the backend servers using a self signed cert as long as the CA has been imported into pfSense.

              L 1 Reply Last reply Reply Quote 0
              • L
                lewis @stephenw10
                last edited by lewis

                That capture shows a simple TCP SYN / SYN-ACK that happens to be on port 443. It's not an actual http or ssl check.
                How is the backend actually configured?

                It only shows up when I enable the HTTP check and it's showing up at 9mn as set so what else could it be?
                And more importantly, there isn't anything set up to connect to the web server on port https. Any traffic would come from haproxy.

                There's no reason HAProxy can't connect to the backend servers using a self signed cert as long as the CA has been imported into pfSense.

                With the config as shown below, the correct acme cert is actually being used but I need the traffic to be sent using http since once this is working, I'll add varnish back into the mix. Varnish isn't working because it's receiving https traffic and the web server as things are now, is not receiving any data from clients.
                The only thing not shown is the rule which I've described above. It's a rule, receiving https on the VIP so that haproxy can access.

                Backend;

                backend0.png
                backend1.png

                Frontend;

                frontend1.png
                frontend2.png
                frontend3.png
                frontend4.png
                frontens5.png
                frontend6.png

                1 Reply Last reply Reply Quote 0
                • stephenw10S
                  stephenw10 Netgate Administrator
                  last edited by

                  Ok, you can see there that the http health check should perform an actual http options request against the server and see a reply.

                  The backend servers would not be using an ACME cert if they are selfsigned. The CA cert you need to import is whatever created the selfsigned certs.

                  You previously said you could not use http to the backend because the website was hardcoded with https links. Has that now been resolved?

                  L 1 Reply Last reply Reply Quote 0
                  • L
                    lewis @stephenw10
                    last edited by lewis

                    @stephenw10 said in SSL certs handling and HAproxy:

                    Ok, you can see there that the http health check should perform an actual http options request against the server and see a reply.

                    Correct but it shows up on the web server as https as shown in the tcpdump.

                    The backend servers would not be using an ACME cert if they are selfsigned. The CA cert you need to import is whatever
                    created the selfsigned certs.

                    According to the remote ssl tests I'm running, it's the correct acme cert on pfsense that is showing up. There are no ssl errors but the web server keeps getting https traffic rather than http from haproxy.

                    You previously said you could not use http to the backend because the website was hardcoded with https links. Has that now been resolved?

                    Yes, quite a number of comments back :). The web server is using a self signed cert but the acme cert is the one in play when public connections are coming in.

                    kiokomanK 1 Reply Last reply Reply Quote 0
                    • kiokomanK
                      kiokoman LAYER 8 @lewis
                      last edited by

                      @lewis
                      take in mind that if initially you configured the backend as https and after that you modified the settings to use port 80 it does not work. you need to delete the backend and reconfigure it with the correct value.
                      there are some bugs lurking around

                      ̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿
                      Please do not use chat/PM to ask for help
                      we must focus on silencing this @guest character. we must make up lies and alter the copyrights !
                      Don't forget to Upvote with the 👍 button for any post you find to be helpful.

                      L 1 Reply Last reply Reply Quote 2
                      • L
                        lewis @kiokoman
                        last edited by

                        @kiokoman

                        First, I've been wondering if I'm coming across a bug again.
                        Second, I've been considering starting all over again but I've tried so many things that at this point, I think I'll make a mistake in the config.
                        I will give it a try now however.

                        1 Reply Last reply Reply Quote 0
                        • L
                          lewis
                          last edited by lewis

                          I tore it all down and rebuilt it.
                          There's definitely a bug alright. Doing that, now I see http heartbeat finally.
                          The ssl cert checks out as the one in acme on pfsense.

                          Incoming connections to the web server are now http as they should be but, public connections are now getting;

                          The page isn’t redirecting properly

                          I know http works fine because I've tested it from other servers and the web server responds as it should.

                          I find it a little hard to believe that if this is a bug that it's not well known?

                          stephenw10S 1 Reply Last reply Reply Quote 0
                          • L
                            lewis
                            last edited by lewis

                            tcpdump on the web server;

                            12:32:54.007855 ens18 In  IP _gateway.28554 > r9ty01.phx.loc.http: Flags [S], seq 3274415560, win 65228, options [mss 1460,nop,wscale 7,sackOK,TS val 511869013 ecr 0], length 0
                            12:32:54.008023 ens18 Out IP r9ty01.phx.loc.http > _gateway.28554: Flags [S.], seq 266390645, ack 3274415561, win 65160, options [mss 1460,sackOK,TS val 2446701473 ecr 511869013,nop,wscale 7], length 0
                            
                            
                            

                            The redirection error is odd since it's not happening from any other internal client.

                            1 Reply Last reply Reply Quote 0
                            • L
                              lewis
                              last edited by lewis

                              I checked using curl and a windows machine on the lan, all reach the web server as they should.
                              Only public connections are getting the 'redirect' error.

                               - - [02/Jan/2024:12:55:32 -0700] "GET / HTTP/1.1" 301 4690 197049 196471 "-" "Mozilla/5.0 (Windows NT 10.0; rv:109.0) Gecko/20100101 Firefox/115.0"
                              
                              
                              1 Reply Last reply Reply Quote 0
                              • L
                                lewis
                                last edited by

                                Just for giggles, I changed haproxy to point to varnish and that is now working too.
                                Meaning, it's sending the traffic to the web server using http.

                                At this point, all I can think of is that there is something in the headers being sent from haproxy which is causing this constant 301.

                                1 Reply Last reply Reply Quote 0
                                • stephenw10S
                                  stephenw10 Netgate Administrator @lewis
                                  last edited by

                                  @lewis said in SSL certs handling and HAproxy:

                                  The page isn’t redirecting properly

                                  How exactly are you testing when you see that? From some external IP? Using http?

                                  Is HAProxy configured to redirect http to https?

                                  L 1 Reply Last reply Reply Quote 0
                                  • L
                                    lewis @stephenw10
                                    last edited by

                                    I guess you missed some of my comments.

                                    Is HAProxy configured to redirect http to https?
                                    How exactly are you testing when you see that? From some external IP? Using http?

                                    The traffic is finally hitting the server as http so that part is solved.

                                    I've tested from internal (LAN) clients using curl and firefox to http since the firewall is handling the ssl cert.
                                    Internally, all is good, web pages are being served up using http.
                                    Externally or public, everything gets a 301.

                                    From external connections, I'm connecting to https and can see the traffic being sent from haproxy to http.

                                    kiokomanK 1 Reply Last reply Reply Quote 0
                                    • kiokomanK
                                      kiokoman LAYER 8 @lewis
                                      last edited by

                                      @lewis
                                      what are you running on the server? apache2 ?
                                      that's usually a misconfiguration in the web server, maybe a redirection on the config that you don't need anymore

                                      ̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿
                                      Please do not use chat/PM to ask for help
                                      we must focus on silencing this @guest character. we must make up lies and alter the copyrights !
                                      Don't forget to Upvote with the 👍 button for any post you find to be helpful.

                                      1 Reply Last reply Reply Quote 0
                                      • L
                                        lewis
                                        last edited by

                                        I checked the incoming headers and for some reason, http is still being forwarded to https so I think the problem is with the web server at this point.
                                        It's odd because there is no forwarding configured, at all on the web server so I'll spend some time on this and see what I can discover.

                                        It's darn close now that I've rebuilt the haproxy config.

                                        kiokomanK 1 Reply Last reply Reply Quote 0
                                        • kiokomanK
                                          kiokoman LAYER 8 @lewis
                                          last edited by

                                          @lewis
                                          that error is usually from a redirect in the web server, haproxy try to comunicate with the web server via http but the server answer back via https but since haproxy is expecting HTTP traffic, it keeps resending the same request, resulting in a redirect loop

                                          nginx could have something like -> return 301 https://$server_name$request_uri;
                                          apache2 could have something like -> RewriteEngine / RewriteCond / RewriteRule

                                          ̿' ̿'\̵͇̿̿\з=(◕_◕)=ε/̵͇̿̿/'̿'̿ ̿
                                          Please do not use chat/PM to ask for help
                                          we must focus on silencing this @guest character. we must make up lies and alter the copyrights !
                                          Don't forget to Upvote with the 👍 button for any post you find to be helpful.

                                          1 Reply Last reply Reply Quote 0
                                          • L
                                            lewis
                                            last edited by lewis

                                            So what seems to be happening is that because the site was built with all urls being https, no matter if I hit it using http, the urls are all htps so the browser keeps getting https.

                                            I dumped the application db, edited all the links to be http and it 'sort of' works.
                                            I can fix the problems but it's not going to solve the main problem which is the sites cannot all be rebuilt to be http.
                                            So, all this for nothing ti seems unless there's some way to get https pages working with haproxy as well.

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