@SteveITS said in Unbound restarts on each run of rc.newwanip:

Ah
https://redmine.pfsense.org/issues/12612

Yeah - I read that too ... The patch inside resolved the problem in 2.6.0 ...

Reads like it should be fixed in 2.7 though…

Looks as it right back ...

@johnpoz hahahaha yeah, well in my defense there are a few posts on this forum around this feature. People (like me) are a bit surprised that this is not supported and in the same time a bit disapointed, since it's quite a basic feature.
In the same time, you're not wrong about the dedicated DHCP server.
Myself I have the scopes configured on my 3750x switch, however would love to have them configured on the pfsense box. I love the gui, I can't help it.

@johnpoz likely am going to use one of these scripts to accomplish the task. This might be the only way to do it.

Thanks

@timeslice I'd pay to have this feature implemented. I have a similar setup like yours and I ended up configuring DHCP on my L3 switch.

@itworx this would be a very nice feature to have.

@Ethereal

I just gave a thumbs up ... As you need 5 (I think) , in order to be able to post wo. restrictions.
Maybe some others could do the same , until you reach 5.

/Bingo

@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 :

bc708cdc-6436-4e05-a6a0-c0ce921bbdd6-image.png

then they are put there because this has been checked :

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.