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

    DNS not being issued to clients until after captive portal login

    Scheduled Pinned Locked Moved DHCP and DNS
    4 Posts 3 Posters 959 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.
    • M
      mozartatplay
      last edited by

      I've been scratching my head on this one. When I have captive portal enabled and before succesful login - no DNS is issued by DHCP to my clients (/etc/resolv.conf is blank on my mac). After I have logged into the captive portal or when captive portal is disabled - my clients are issued a DNS by pfsense DHCP server (I can see the DNS in /etc/resolv.conf on my mac).

      I have a number of local services (with different host names on a local domain) on a private subnet on a local server that I need clients to access - hence the need for DNS before clients login on the captive portal

      I'm running pfsense 22.01

      I have tested this with DNS Forwarder and DNS Resolver. I have set these to use the DNS in my System / General Setup

      My DHCP server is very standard I'm issuing addresses on a VLAN through a managed switch to a 10.15.0.0/16 subnet. I don't set any DNS servers on the DHCP server setup so that it uses the system default DNS server. I also don't set any Other options.

      Any tips to overcome this?
      Thanks!

      M GertjanG 2 Replies Last reply Reply Quote 0
      • M
        mozartatplay @mozartatplay
        last edited by mozartatplay

        @mozartatplay Some further investigation with wireshark shows that the DHCP ACK returned to the client does contain the DNS (Option: (6) Domain Name Server) but the client (My Mac) does not use this DNS record until the user either authenticates with the captive portal or chooses to close the captive portal screen.

        On Android - I can't use the DNS offered DHCP when using the pfsense captive portal until authentication is completed.

        This is a big problem if you want to run local offline services (before authenticating to use the internet) that require a hostname (not an IP address - and need a DNS) - I have links to these local services on the cpative portal page

        johnpozJ 1 Reply Last reply Reply Quote 0
        • johnpozJ
          johnpoz LAYER 8 Global Moderator @mozartatplay
          last edited by

          @mozartatplay I don't believe the captive portal auto adds the IP of your dns server, even when its pfsense IP.

          You most likely have to add the IP your pointing the clients to, even if its pfsense own IP to the allowed IPs without auth.

          States this on the captive portal setup page

          "Also, the DNS Forwarder or Resolver must be enabled for DNS lookups by unauthenticated clients to work."

          An intelligent man is sometimes forced to be drunk to spend time with his fools
          If you get confused: Listen to the Music Play
          Please don't Chat/PM me for help, unless mod related
          SG-4860 24.11 | Lab VMs 2.7.2, 24.11

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

            @mozartatplay said in DNS not being issued to clients until after captive portal login:

            Any tips to overcome this?

            These are the settings of the DHCP server of my 'PORTAL' network, 192.168.2.0/24 :

            53d69f84-4a30-4d06-b561-d740268fe201-image.png

            I did set 192.168.2.1 as the DNS server. I'm not sure if that is actually needed, if pfSense is the networks DNS also.
            Unbound (pfSense) is listening on that interface.

            Debugging the DHCP session on te user side : it gets an DNS server.

            ipfw firewall rules do permit DNS traffic, even when the device isn't logged into the portal yet.

            @mozartatplay said in DNS not being issued to clients until after captive portal login:

            the client (My Mac) does not use this DNS record until the user either authenticates with the captive portal or chooses to close the captive portal screen.

            If your device doesn't want to use a DNS given by an upstream router/DHCP server, your connection will be mostly useless.
            Never saw such a thing while using iPad's or iPhones.
            These devices will NEED a DNS as the throw out automatically a http://www.apple.com/captivepoprtal.html test page to check if the device is behind a captive portal.
            For "www.apple.com" to resolve, a DNS must work.

            @mozartatplay said in DNS not being issued to clients until after captive portal login:

            This is a big problem if you want to run local offline services (before authenticating to use the internet) that require a hostname (not an IP address - and need a DNS) - I have links to these local services on the captive portal page

            Keep in mind that most of the captive portal support is build in the devices using the captive portal. Not pfSense !! pfSEnse just uses some clever firewall rules - and it redirects http (port 80) http requests) for device that are not authenticated yet.
            These devices throw out a http ( not https ! - no one can't redirect https ) request.
            Every device, actually, the OS, can chose whatever http domain is used. A working link to the Internet is not an really option when you want to use the (pfSense) captive portal.

            But, if I cut my WAN connection, the captive portal login page still pops up : the request to http://www.apple.com/captivepoprtal.html test page (I used my iPhone) failed after a DNS timeout (might be rather long).

            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.