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

    Captive portal & external DNS Server - not redirecting

    Captive Portal
    captiveportal captive portal dns resolver dnsbl
    2
    5
    659
    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.
    • sazanofS
      sazanof
      last edited by

      Hello everyone!

      Next rules:
      x.x.144.1 - PF
      x.x.144.10 - Win Srv (DC, DNS, DHCP roles)

      Tell me, I set up captive portal (dhcp, dns resolver) on pf and enabled
      Enable HTTPS login option.

      I checked, everything works, opens the authorization page and it passes successfully.

      I want to use a DNS server on DC (there is also DHCP sevice on it).

      Well, I turn off the PfSense DHCP server, turn on DHCP on the domain controller, in the DCHP options I specify the DNS server PF (144.1) - it works well.

      I changed the address of the DNS server to another one (144.10) in the DHCP parameters (which is raised on the domain controller) + I added this IP 144.10 in the portal's captive settings in allowed ips, then redirection does not work 😠 , sites open without authorization.
      The authorization page opens manually (copy-paste).

      How can I force captive portal to redirect if clients use another DNS server (on my DC)? I want to use one DNS server with 144.10 on DC instead of DNS PfSense.

      Please, help!

      In addition, I use DNSBL to perform a Safe Search

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

        @sazanof

        What about this one : on the DHCP server you use, tell it to send your 144.10 server as the DNS server.

        Now, get a device, activate the wifi - or wire, and connect to the portal ntwork. Do not loggin.
        Check on that device with ipconfig /all ( or equivalent) what IP, gateway and DNS it received.

        The pf portal will, of course, block this 144.10 IP, so you have to add it to the "allowed IPs" list on the portal.

        Now : without using the captive portal login page - no browser nothing, ; can you do a dig or nslookup on the device connected to the portal network ?
        Does it use the 114.10 device ?
        Can you see the DNS request coming in on that DNS 144.10 ? And the answer ?

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

        sazanofS 1 Reply Last reply Reply Quote 1
        • sazanofS
          sazanof @Gertjan
          last edited by

          @Gertjan hello! Yes, of course I did all of this:

          On my DHCP server option 006 is 144.10

          ipconfig /all - shows DNS Server 144.10 on client

          nslookup google.com - also shows DNS Server 144.10 on client

          nslookup google.com
          Tõ¨òõ¨:  UnKnown
          Address:  192.168.128.10
          google.com
          Addresses:  2a00:1450:4010:c0e::66
                    2a00:1450:4010:c0e::8a
                    2a00:1450:4010:c0e::65
                    2a00:1450:4010:c0e::8b
                    142.250.150.101
                    142.250.150.102
                    142.250.150.113
                    142.250.150.138
                    142.250.150.139
                    142.250.150.100
          

          OR

          nslookup lipsum.com
          Tõ¨òõ¨:  UnKnown
          Address:  192.168.128.10
          
          Lü :     lipsum.com
          Address:  34.85.243.109
          

          In the diagnostics section "Packet Capture", I noticed that the packets go to port 53 of address 192.168.1.1 (???). But there is no such address in my test network.

          I decided to look into the properties of the DNS server on windows server and the server 192.168.1.1 was listed in the forwarding server. I fixed it to 144.1 (pf).

          So now, when client open for ex. lipsum.com or someone else - the portal page opens, but there is no redirection for a very long time (about 20 seconds). If you open an IP address with some kind of web interface in the browser, then redirection to the portal page occurs instantly. Why?

          @Gertjan said in Captive portal & external DNS Server - not redirecting:

          The pf portal will, of course, block this 144.10 IP, so you have to add it to the "allowed IPs" list on the portal.

          Yes, I read the troubleshooting guide for the portal, and the first thing I did was register IP 144.10 in the portal settings "allowed IPs".
          And if I do this, there is no redirection to the portal page, all sites open without requiring authorization. Why?

          And I understand that most likely this is another topic, but nevertheless, it may be related: DNSBL on pfBlockerNG not work. There is no redirect on "access denied page". =(

          The SafeSearch section and the rules in DNS Resolver for safe search work, but if I open blacklisted site in the browser, it will open without redirect to DNSBL error page. It's also unclear what went wrong.

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

            @sazanof said in Captive portal & external DNS Server - not redirecting:

            So now, when client open for ex. lipsum.com or someone else - the portal page opens, but there is no redirection for a very long time (about 20 seconds). If you open an IP address with some kind of web interface in the browser, then redirection to the portal page occurs instantly. Why ?

            What a device, the OS actually, should have to do: as soon as DHCP negotiation finishes, it will send a http (not https !) request to a build in URL. For Apple device, this "http://captive.apple.com/hotspot-detect.html". If this does not return (click on the link to see the answer) "Success", then the OS knows there is no direct Internet connection. So, maybe a captive portal ? It will spin up a default web browser with the same URL again.
            This "any IP destination, destination port 80 => redirect to IP of the portal interface, port 8002" action, a firewall rule, will produce not "Success" but our login page.

            No why this does not happens on your device : ask your device ? 😊

            For instance, most browsers want to out smart us by totally ignoring system's DNS, and use their own DOH or whatever .... and yeah, that will hit the wall ... portal.

            Keep in mind also that the portal is the server (web server) and you have the client.
            The portal page isn't send or pusched to you.
            You see it when you (the browser or the system) asks for it.

            Why your device doesn't ask for it ? Dono.

            Btw : when the portal login page opens, and you validate that page with a valid login, the IP & MAC of your device are added to the OK-table in the firewall. And then, as a result if the POST (to login) of your browser, it will receive a URL redirect to the original URL it wanted to visit initially.

            What I do : I redirect the user to a well known site, that shows up fast, and proofs that the user is connected :

            08745411-579e-4b89-b10e-979654736e2a-image.png

            From there on, they will know what to do.

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

            sazanofS 1 Reply Last reply Reply Quote 1
            • sazanofS
              sazanof @Gertjan
              last edited by

              @Gertjan

              Yes, it turns out a whole trip to the theater.😊
              Also, it turns out that the problem is solved, the solution (in my case) is found, published. Maybe it will help someone.

              Thank you very much!

              As for DNSBL - perhaps I will create a new topic.

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