@skilledinept now kicking myself in hindsight when he posted dhcp.conf - that I missed this option custom-lan-0 code 1 = text;

@Gertjan I reapplied the patch after upgrading to 22.05 and it worked without the timeout issues. Thanks again for all your help!

@rayures //edit for now i replaced my bind zone cname entry with a ddns provider that is updated via the pfsense ddns client that is holding the current ip until the client changes it.

@johnpoz I have had the fiber provider's DNS go down (2 servers) while the data was still up so had to temp redirect all DNS to an external server until it was fixed. But yes, I do understand these single dns IPs are anycast, which is why I say the probability is small. The bit about turning off rebind protection seems circular. I get a loss of security just to keep the log clean. In this discussion it has been mentioned it's not a good idea to disable the protection rebind offers so I'm confused your suggesting it again. Why de-harden a firewall only to reduce log entries? This would invite external access to an internal device if they were lucky enough to set a public dns to a private IP that was valid to my local network. As for handing out public dns via dhcp, I'm doing that now to the forwarder. To do all customers external would be a system wide performance hit. Is there a way to hand out a public dns via dhcp by individual IP or alias leaving all others to use the system general settings pointing to the forwarder (127.0.0.1)?

@viragomann My gateway group was created at midnight under a full moon? :) There is nothing I know of that could make it be special. System/Routing/Gateway Groups Wan0 Tier2 VPN Never Wan2 Tier1 Default gateway IPv4 = GatewayGroup1 Under General Setup it's interesting it says "Optionally" "Optionally select the gateway for each DNS server. When using multiple WAN connections there should be at least one unique DNS server per gateway." It punches a hole in my VPN routing of many IP ranges since my DNS servers exist in the IP segments I need to access using my VPN forcing each DNS server to use that gateway. netstat -r default = IP of the tier1 gateway ns1.myowndnsserver.com IP of chosen gateway. ns2.myowndnserver.com IP of chosen gateway My VPN I can chose the gateway group as its operating endpoint. But also it will stay on whichever wan is working. If it's on one that is removed for latency it will switch WANs and stay there until that WAN has latency issues even when the other tier1 wan comes back. It does not just jump back or attach to say a group Non routable IP that points to whatever wan is best at the moment. (Which is another flaw as unless you log into the shell you have no idea which WAN your VPN may be using. I can get not auto switching as that would drop the connection and have to re-establish which sucks for things like ssh) So yes it is very annoying that DNS servers are being tied to a particular route so that if that route goes down, that DNS server will not respond. I have not seen any other setups so as far as I know this is a flaw. I mean it says "When using multiple WAN connections there should be at least one unique DNS server per gateway." So it seems like my not having this choice is by design.

Issue has been resolved successfully upgraded to 22.05.

@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 : [image: 1656261716325-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).

@zweany DHCP has a lease time, which means a device "owns" the address for the lease time. That might be the issue. PfSense has a utility called Packet Capture, which can be used to see what's actually happening. Give that a try and learn a bit about DHCP in the process. When you use Packet Capture, you probably want to download the capture and examine it with Wireshark.

@pwood999 [image: 1655997607557-bce4af0d-6086-4ca5-b173-06cbc62f288a-image.png] Be careful with that setting "Network interfaces : LAN ( and only LAN ). You saw the 'Localhost' at the bottom of the list ? You've omitted to select that one. Result : pfSense itself, that is, code like the GUI, will consult what that IP. Not the LAN, not the WAN. Local software, like on your phone and PC will consult always 127.0.0.1 or Localhost or ::1 On localhost, port 53, is running a local DNS 'collector' that will forward to an (that's what a typical Windows PC does) upstream router. As per instructiosn by the local DHCP server (pfSense) and the local DHCP client your your PC. Type ipconfig /all to see your local DNS setting : it's most probably 192.168.1.1 == the LAN IP of pfSense and pSense is (should !) listen on that interface. Actually, it's a no brainer : just keep "All" selected for both "Network Interfaces" and "Outgoing Network Interfaces". That's the default settings, created by Netgate after years of investigation. It's not an issue that unbound is listing on some WAN type interface : nothing can come into the WAN anyway. And before you say : but that is dangerous !! Don't worry. It' looks scary because you think it's scary. The Web server GUI nginx is also listing on All available interfaces ( but don't tell any body, as you might wake up the thin foil hat association ) [22.01-RELEASE][root@pfSense.mypfsense.net]/root: sockstat -4l | grep 'nginx' ...... root nginx 98071 5 tcp4 *:443 *:* root nginx 98071 6 tcp6 *:443 *:* root nginx 98071 7 tcp4 *:80 *:* root nginx 98071 8 tcp6 *:80 *:* root nginx 97984 5 tcp4 *:443 *:* root nginx 97984 6 tcp6 *:443 *:* root nginx 97984 7 tcp4 *:80 *:* root nginx 97984 8 tcp6 *:80 *:* root nginx 97740 5 tcp4 *:443 *:* root nginx 97740 6 tcp6 *:443 *:* root nginx 97740 7 tcp4 *:80 *:* root nginx 97740 8 tcp6 *:80 *:* which means : listen on every interface for every 443 and 80 using TCP. Every interface == "All".

@johnpoz Thank you so much for the quick and informative reply!!!!! I just set mode to static and it works perfectly. When setting this up, I read the description provided in the UI, and it didn't seem to matter for my installation. So I left it as Transparent. pfSense is absolutely great! But, there are so many settings (which allows you do so much), you need a solid education in every aspect of firewalls/routers/DNS/DHCP/etc to get everything right. Like I said, I love pfSense .,.. it can be tough to navigate everything though. Thanks again!!

@johnpoz Hehe, I really don't see it as rant and I for one am very grateful for the long and detailed response. I think I have a better understanding of it now and have personally had experience with noisy networks (sonos) sending tons of multicast packets flooding the network. I use home assistant a lot and some features need mDNS specifically to work smoothly and get discovered "magically", and honestly, just the thought of configuring everything manually makes my head ache, because I know I would spend more time with it than I would be happy with :)

Nothing to add right now, other than: count me in as someone who hopes this gets addressed. The closest we've come appears to still be this draft PR from 2+ years ago. I personally don't use the "register DHCP leases" option but most customers expect stuff like "a device named LAPTOP_3f7ea4 connects to the network, then try to connect to smb://LAPTOP_3f7ea4 should work"...

@droidus said in DNS not responding to client queries: It is set to listen on Localhost As @SteveITS mentions if you only have it listening on localhost then it couldn't respond to anything but itself asking, unless you had a forward setup to localhost.

Thanks! That worked. Awesome!

@gertjan -After Wan is active, DNS resolver does not start automatically. We will review your suggestions. thank you

related: https://www.reddit.com/r/PFSENSE/comments/vdrxkp/what_exactly_is_supposed_to_happen_when_pfsense/ and https://forum.netgate.com/topic/172849/rtsold-not-running-ipv6-wan-dhcp-keeps-losing-connectivity