@johnpoz @keyser So ty for the screenshot, I didn't have source advanced matched correctly.. And I was trying to redirect to another host.. so I am now seeing ntp clients on the router.. but of course (without physically going to each host..) I have another question.. pfsense host tcpdump -v -i igb0 dst port 123 and src net 10.20.0.0/16 -n -vvv bare metal (void) linux host.. tcpdump -v -i enp1s0f0.173 dst port 123 and src net 10.20.0.0/16 -n -vvv [image: 1657326398429-657bfd16-2a1f-4e81-994a-f9b8f7bbdce7-image.png] What is up with all the time disparities? 1 and 4 look fine.. what is up with 2, 3, and 5? The host on top is pfsense and running ntpd, host on bottom is running chronyd.. host 1 is another pfsense, host 2 is a bare metal linux which locally reports correct time, host 3 is an esxi vm also locally reporting correct time, host 4 is an esxi windows vm locally reporting correct time, host 5 is an axis camera locally reporting correct time.. I just wouldn't have expected to see all those different times.. This was the host I was testing from originally.. (which also looks correct locally and in the tcpdump..) [image: 1657326939985-a1f81a54-a519-4357-a250-dfaca34d2e04-image.png] Random host had this to say about tcpdump timestamps.. (https://weberblog.net/packet-capture-network-time-protocol-ntp/) "transmit timestamp: “Time at the server when the response left for the client.” This is the most interesting timestamp in those NTP packets since it shows the time the NTP client/server had as it sent the NTP packet. If you roughly want to know the time by looking at an NTP packet, look at this transmit timestamp."

@rcoleman-netgate No. I have one lan interface from the pfsense router that connects to a switch. They are all in the default VLAN.

@ofir29200 said in DHCP wont start after a power outage: 10 PC was running 1 year straight without a power outage (but then it became unresponsive, so I had to reboot it...) That's pretty darn good for a consumer grade desktop OS. Still, as this is consumer desktop OS, after the reboot I would bet heavily on "issues" after such a period. You were also skipping major security updates .... that's something I wouldn't even dare to do.

@deanfourie said in Huge DNS traffic?: pi Thinks get easier now. Who admins this thing ? You ? Go for the easy choice : rip it out of your network. Solved ;) Or go for the Youtube 'wtf is a pi anyway' series. You be in for some pretty good DNS info ;) edit : Btw : pi and pfBlockerng-devel do somewhat the same thing. Using both == annoying a best.

@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".