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

    HTTPS Forwards doesn't work

    Scheduled Pinned Locked Moved Captive Portal
    7 Posts 3 Posters 2.2k 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.
    • D
      deltix
      last edited by

      With captive portal enabled, HTTPS login enabled and "Disable HTTPS Forwards" checked request to https sites hangs, it's not being passed through nor forwarded to the captive portal. I'm trying to prevent certificate error until user hits http site and then forward it to the captive portal for authentication.

      1 Reply Last reply Reply Quote 0
      • DerelictD
        Derelict LAYER 8 Netgate
        last edited by

        What you are trying to do is impossible.

        That's what the Disable HTTPS forwards checkbox is designed to do: Allow you to have an HTTPS captive portal page without presenting users with an HTTPS certificate error if their initial request is an HTTPS site.

        You cannot answer an HTTPS request with a captive portal (really just a man-in-the-middle) without generating a certificate error. That's sort of the whole point of HTTPS/SSL/TLS.

        Chattanooga, Tennessee, USA
        A comprehensive network diagram is worth 10,000 words and 15 conference calls.
        DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
        Do Not Chat For Help! NO_WAN_EGRESS(TM)

        1 Reply Last reply Reply Quote 0
        • GertjanG
          Gertjan
          last edited by Gertjan

          @deltix:

          …. until user hits http site and then forward it to the captive portal for authentication.

          Captive users do not need to know anything about your captive portal. They will just ‘see’ the login page. This magic always work, if everybody respects the rules.
          When you use a Wi-Fi network, everybody knows they should enter a Wifi password. Without that password, they cannot use the (neighbors ;) Wi-Fi network.
          This, again, is known and most people understand why.

          "Captive portal networks" do (most often) NOT use this of protection to connect to its network.
          The Ethernet (by radio or wire) connection is just established as soon as you select it / hook it up.
          Remember: "Captive portal networks" are not only Wi-Fi networks, they could be wired also.

          So, as about everybody (will) see the login page : another type of authentication is needed.

          When not authorized yet, ALL initial http (http, not https **) requests are redirect to a web server that present you the …. Captive portal login page.
          The 'http' word implies an important detail: only web browser use http - because only web browser can show something that a user will recognize as a page where they have to authenticate themselves.

          Now, the nasty part: by nature and protocol law: initial httpS request will NOT be redirected - will NOT be intercepted - period.
          Even if they are, the browser will refuse at best and show a huge certificate error at least.

          Even without fully understanding, https requests should not be intercepted.
          So, now comes the situation: an initial https request (like the navigator's starting page https://www.google.com) AND a captive portal, who intercept by design, cannot function together.
          The user's navigator will refuse.
          Ok, now you saw the whole picture, you'll understand that most OS's like Windows (all versions), MAC OS, iOS (Apple), and I guess also al kind of Samsung stuff will detect the portal (they issue a **hidden http:// ** request, initiated by the OS as soon as the Ethernet connection comes up) and opens a default navigator which will allow the user to see and use this login page.

          The nasty one: user tend to activate (without them actually really knowing what they are doing) all kind of protection schemes like "never connect to a strange network" ....
          Or commercial firewall rules that really works great at home - and nowhere else (well, they are served !!)

          Just member this one :
          A NEW device
          iPhone / iPad / PC / Whatever, it will connect just fine to a captive portal.
          At least, this is what I saw for the last several years, using a pfSense captive portal for a hotel.

          If it doesn't work, ask the user (device owner) what they did to mess up their device ;)

          No "help me" PM's please. Use the forum, the community will thank you.
          Edit : and where are the logs ??

          1 Reply Last reply Reply Quote 0
          • D
            deltix
            last edited by

            From description "If this option is set, attempts to connect to SSL/HTTPS (Port 443) sites will not be forwarded to the captive portalThis prevents certificate errors from being presented to the user even if HTTPS logins are enabled. Users must attempt a connecton to an HTTP (Port 80) site to get forwarded to the captive portal. If HTTPS logins are enabled, the user will be redirected to the HTTPS login page." My understanding is that if browser requests https pfsense will just pass it through. Is that correct? If it is then it doesn't work as expected. Or I don't understand how this option works. BTW, I do understand the whole thing about captive portal and certificates, I do not question that.

            1 Reply Last reply Reply Quote 0
            • DerelictD
              Derelict LAYER 8 Netgate
              last edited by

              No. The connections just appear to hang. They're not through the portal yet.

              Chattanooga, Tennessee, USA
              A comprehensive network diagram is worth 10,000 words and 15 conference calls.
              DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
              Do Not Chat For Help! NO_WAN_EGRESS(TM)

              1 Reply Last reply Reply Quote 0
              • D
                deltix
                last edited by

                Basically still doesn't work as intended. Correct? I can just forget I guess.

                1 Reply Last reply Reply Quote 0
                • GertjanG
                  Gertjan
                  last edited by

                  @deltix:

                  Basically still doesn't work as intended. Correct? I can just forget I guess.

                  Define your 'intended'.
                  According to RFC and family, all is ok.
                  But, breaking https (SSL) connections isn't easy - but it can be done.
                  Like : a visitor is hitting the (your) portal with https://www.google.com - You generate a certificate (on the fly) that says your portal IS "google.com", and you better assure that a major certificate broker says that google.com is YOU (your portal). Then, the visitor's browser will be happy …. and your visitor can log in (would he really think he IS visiting google.com at that moment ?  ;)). When done, you portal will redirect the visitor the other, real google.com https site.
                  Can you pull this one off ?

                  No "help me" PM's please. Use the forum, the community will thank you.
                  Edit : and where are the logs ??

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