@johnpoz said in Come on, let us create DHCP reservations inside the pool: making reservations inside a pool, seems like just pointless non feature One scenario where it's useful is when a client installs a printer/scanner/whatever, then calls us. It's easier to make the IP permanent than try to log in to the device and set one (edit: esp. if they started using it). Just saves us time hence them money. (and yes if we set it up we have a pattern for printer IPs... )

@koy Are you trying to connect to your WAN IP port 443 from LAN? If so you need to enable Reflection on the NAT rule. Otherwise you'll connect to the pfSense web server, and see that message. Or use Split DNS instead. https://docs.netgate.com/pfsense/en/latest/nat/reflection.html

@bmeeks I solved it by copying both the curl and sh binaries into the chrooted folder and specifying the path to them directly: mkdir -p /var/dhcpd/bin mkdir -p /var/dhcpd/usr/local/bin cp /bin/bash /var/dhcpd/bin/ cp /usr/local/bin/curl /var/dhcpd/usr/local/bin/ Then in my /var/dhcpd/etc/dhcp_update.sh script: #!/bin/sh BASE_URL="http://your-web-server.com/your-endpoint" EVENT_TYPE="$1" IP_ADDRESS="$2" MAC_ADDRESS="$3" case "$EVENT_TYPE" in "1") ONLINE_STATE="online" ;; "2"|"3") ONLINE_STATE="offline" ;; *) ONLINE_STATE="unknown" ;; esac URL="${BASE_URL}?ip=${IP_ADDRESS}&mac=${MAC_ADDRESS}&state=${ONLINE_STATE}&event=${EVENT_TYPE}" echo "DHCP Announce: $URL" /usr/local/bin/curl -X GET "$URL" It aborted with exit code 6, which means that cURL couldn't resolve the hostname (good news!). I still haven't tested this with my proper endpoint, but I think it will work now.

@noitalever said in Website won't resolve. says DNS_PROBE_FINISHED_NXDOMAIN: advanced privacy options in the dns resolver I had checked. And what are those? You were forwarding somewhere over tls?

Here is a link to how I did it. https://forum.netgate.com/topic/156453/pfsense-dns-redirect-to-local-dns-server?_=1663853296484

@mmiller7 The following Unbound/DNS Resolver Custom options to remove all local and external domain AAAA responses in replies given to clients should be what you're looking for: server: do-ip4: yes do-ip6: no prefer-ip4: yes prefer-ip6: no private-address: 10.0.0.0/8 private-address: 172.16.0.0/12 private-address: 192.168.0.0/16 private-address: 169.254.0.0/16 private-address: ::ffff:0:0/96 private-address: fd00::/8 private-address: fe80::/10 private-address: ::/0 private-address: :: local-zone: localhost.home.arpa transparent local-data: "localhost.home.arpa A 127.0.0.1" local-zone: localhost transparent local-data: "localhost A 127.0.0.1" local-zone: ip6.arpa redirect local-data: "ip6.arpa A 0.0.0.0" local-zone: 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa redirect local-data: "1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.ip6.arpa A 0.0.0.0" local-zone: "::/0" static dns64-ignore-aaaa: *.* do-not-query-address: :: do-not-query-address: ::1 do-not-query-address: ::/0

@marchand-guy too much? No..

@Gertjan said in DNS unresponsive to clients: Nowhere they say that you need (have to) to modify it. Nope nothing saying you need to modify it.. You do you - if you like all, then use all.. Is that the most secure setup or best optimal setup? What I would say is its the "safest" setup for when yo don't know what the network setup will actually be.. So its a valid "default" setup.

@pzanga Another test : run this on the command line : grep 'start' /var/log/resolver.log The idea is to keep the number of unbound restarts as low as possible. A couple of times per week : ok, but many times per hours (example) isn't bad, but during restart, which can take several seconds, your network has no DNS. @pzanga said in clients cannot resolve any google sites (plus on other) but pfsense can: so not sure why the DNS servers were configured when forwarding was not enabled If you didn't enter these : [image: 1686893438132-bc708cdc-6436-4e05-a6a0-c0ce921bbdd6-image.png] then they are put there because this has been checked : [image: 1686893488219-73fcc240-298c-4145-bc6e-ce1f419c0b96-image.png] If your WAN (ISP) uses DHCP, pfSense, upon connection, uses DHCP, and this will deliver an IP, a network, a gateway and ..... one or more ISP DNS. Exactly as what happens when you connect a device (PC, whatever) to your pfSense LAN. These ISP DNS are not used. But pfSense itself can use it if needed, for example, if the top first IP (normally 127.0.0.1 = unbiound doesn't reply) See cat /etc/resolv.conf @pzanga said in clients cannot resolve any google sites (plus on other) but pfsense can: google.com yesterday from the client when I was having issues and that showed 100% packet loss "packet loss" means : google.com was resolvbed, so 'ping' had an IP to work with. Thus DNS is ok. But then there was no path to this IP : this means a bad connection. @pzanga said in clients cannot resolve any google sites (plus on other) but pfsense can: I do see the Chrome (and Edge) settings/flags that can be disabled to prevent them from using DoH. What is considered best practice when it comes to that? Should I disable those settings? Should I use pfsense rules to force all DNS requests to use the local DNS? Or just leave it as is (assuming that it isn't the cause of my problem). Ok, you are aware that 'programs' like web browser can do tings their own way. Its up to you to chose what you prefer to use, and what happens when and how. This info is important when you want to debug things.

@RobbieTT Yep, I've been leaving the leases alone. I have intermittent issues with Siri not working properly and being very unreliable only on those devices. I suspect since I don't have firewall rules in places for the HomePod Mini IPs, they are blocked from connecting to certain things but without static IPs, I can't do much about it it. I didn't know about Apple having better success with IPv6. I have blocked all that because I couldn't figure out how to assign static IPv6 leases reliably haha My ISP doesn't support IPv6 yet either but I could play around with it locally at least.

@JonathanLee sorry if I wasn't clear. No, one URL should be enough

@johnpoz I thought the DNS Lookup tool would support DoT because pfSense 'supports' DoT by using unbound and I didn't know better. Looking at the source, I now know it uses drill (/src/usr/local/www/diag_dns.php#L111) which doesn't support DoT.

@ivanjrx Moderators can change the status for solved

@johnpoz Alright so I was able to do some more testing, and it is pretty bizarre compared to what I believe should be expected behavior. I've checked a countless times at this point to ensure the MAC from my primary box is set on the WAN interface of the secondary box. I would expect that my modem can not tell the difference between the two boxes, and both pfsense boxes should be able to grab the same IP from my modem if I disable the WAN interface on one of them, or even perhaps both simultaneously, though I would expect issues in that scenario. Here are the steps I took with the results: On pfsense primary, put down WAN interface via ifconfig in SSH session Physically plug ethernet cable from pfsense secondary into trunk port 5 on switch Pfsense secondary shows WAN connection as up, but doesn't receive an IP address Unplug pfsense secondary from trunk port 5, and plug it into trunk port 1 (where pfsense primary was previously plugged in) Pfsense secondary obtains an IP quickly (without modem reboot) and has connectivity - With a different IP address! Unplug pfsense secondary from trunk port 1, replace pfsense primary into trunk port 1. - Pfsense primary grabs the previous IP. I could see it possibly being a switch configuration issue, though I've been over that a dozen times as well. That would not explain pfsense secondary getting a different IP though. My best guess is MAC spoofing is not working somewhere between the interface and modem.

So I updated the resolv.conf file and everything is resolving correct now. But I don't see anything reflecting differently in the UI. So my question, is there a way to persist unique settings in resolv.conf for local DNS to point to local, 127.0.0.1 from unbound forward listed IPs? Once I made this change above, I updated to the latest version, rebooted and my changes are not gone, resolv.conf matches the same forward IPs stated in the UI (screenshot) and in unbound.conf Thanks

@lparker yeah - they are not redirecting 8.8.8.8 maybe... But how would pfsense redirect traffic to itself, especially when you stated you don't have any redirection setup.. And if it was - why would it not redirect 8.8.8.8? You can't do an outbound nat on your wan to yourself.. Sorry but asking 1.2.3.4 for dns and getting an answer is clearly redirection of dns.. period.. Here is an idea - why don't you stop unbound completely.. Now do your query to 1.2.3.4 as your test. Look at your +trace you did from before advantechwifi.com. 0 IN A 199.38.182.75 advantechwifi.com. 0 IN A 199.38.182.52 ;; Received 78 bytes from 199.9.14.201#53(b.root-servers.net) in 36 ms There is no possible way the root server answered with that.. The root servers don't have such info.. So your saying pfsense somehow redirect outbound traffic to itself, and answered with that info? After a restart of unbound how would it have that info in its cache? Do you even have serve zero setup - that is not a default setting.. [image: 1686597826182-unbound.jpg] To prove it to yourself - turn off the unbound service.. Make sure pfsense isn't listening on 53 with netstat or something, now do your directec query tests.. query 1.2.3. 4 etc..

@droidus said in Local DNS resolution & blocking of a domain & pfblockerng: such as the ones surrounding them?: You should always be as specific as possible with rules.. This firewall is not specific to be honest. If this is your lan net, that would be the IP it would be talking to for dns, ie lan address. Why would something on your lan be talking to say opt X on pfsense IP for dns? or you wan IP? "This firewall" is an alias that has all the IPs on pfsense. Do you use this lan net as a transit network? How would something be talking to your lan interface from the lan net coming from any IP other than lan net? There is no reason to have any as the source, unless the interface is a transit network, and even then it should be limited to the IPs as source, why would you not know your downstream networks using this interface as a transit.. Also what client would be using dot? (853) Clients use doh, dot is more for resolvers or forwarders to use.. Also for you to use dot from a client do you have that setup with cert that your clients would trust? What do you have behind pfsense that is using dot? And for that matter why would you need to encrypt dns queries across your own network?