@nhscan
My best suggstions are :

1:
Create a dedicated IoT Lan/Vlan , and do the Internet Access , blockking there.

2:
Make your IoT "Internet Access" block rule, use an Alias for the matching source IP's.
Then it's just a matter of adding the newly created IoT IP, to the Alias.

I would recommend 1 , as you can do a Lan/Vlan wide block.
And it doesn't matter if the IoT "thingy" pull's another DHCP IP by "mistake".

/Bingo

@thisisme
I did some tests and these are the results:

Unbound will look up all configured DNS Server in parallel. So it also uses the DNS Server configured with the WAN Gateway.

If I use package capture there is no traffic for port 53 on my WAN Interface.

If if disable forwarding mode in unbound I pass the dns leak test.

Can I assume that's still safe to use forwarding mode, because the traffic seems to be on VPN Interface only?

Issue reported on redmine: https://redmine.pfsense.org/issues/13719

Figured out what was causing the error. It seems to be caused by the pfBlockerNG-devel package. I had a second router I was setting up and checked the DHCP server functionality after every change. Everything worked fine until I installed the pfBlockerNG-devel package. Uninstalling it does not remedy the issue either. A full factory reset is required.

Package specifics
pfBlockerNG-devel
Version: 3.1.0_11

Workaround
You can reconfigure the interfaces and DHCP Servers via console to the box. Had no issues making changes via console and all of them took.

@camg
If you can run your own Unbound DNS on separate machine you will not be having all these issues.
I have Synology NAS and I compile and build my Unbound straight from Unbound repo. Current version 1.17.
It is a solid solution is you can do this.

Problem with pfsense including Unbound is that there is no way a user can update just Unbound itself. Over this year Unbound released 4 version. You are always behind if you use supplied Unbound binaries with pfsense.

I have used that typo of architecture (separating Unbound DNS) for years. Never had any issues. For these people that use pfBlocker - you can do all domain blocking just using Unbound RPZ. Its easy .

@ahking19 said in PFSense DNS cannot resolve outlook.ha.office365.com properly:

@tdixler

Check Domain name outlook.ha.office365.com, and type as HTTPS<<

HTTPS is not a valid DNS query type. Valid query types are - A, AAAA, CNAME, MX, NS, etc)

Are you confusing with DNS-over-HTTPS (DoH)?

Hmmm ... See:
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-svcb-https-01#section-12.2

Right now it seems like Apple IOS > 14.x, is using this type of queries.

Yddrfff .... DoH bypassing (resolver selection) 😠
https://support.opendns.com/hc/en-us/articles/360049861971-DNS-Resolver-Selection-in-iOS-14-and-macOS-11

Thanks all.
So my solution is to know that my workaround was the solution :)

@crichmon I do not know how to convert. Only GUI interface.

@gertjan said in DNS reslution error just on pfsense box:

ort the config back in, and one reboot later you're back at square 1.

I reinstalled pfsense, left everything as default. It still couldn't resolve DNS.
Ended up upgrading installation boot usb from 2.5 to 2.6, re-installed pfsense once again with all default settings, changed the NIC and it resolved the issue.

I am still unsure what caused the issue though.

Thanks for all your input Gertjan :)

@fsc830 said in DHCP not working as expected!?:

was focused at the pfSense.

What is more likely - you have a rouge dhcp, or pfsense handing out info you didn't set it - and not logging that it handed anything out ;)

@johnpoz

You are right, this android device joined the IOT SSID. On pfsense I have majority of IOT devices static DHCP binding with DNS assigned. But for dynamic DHCP pool I did not specify DNS server. So it was using .30.1 (pfsense gateway) as DNS and I have DNS redirect configured for external DNS servers not pfsense itself. This is resolved.

Thank you very much for pointing out the issue.

Got it! I had to add "LAN" to the list of authorized outbound network interfaces for unbound. Without that, it wasn't able to send traffic from an IPv6-enabled interface (since my WAN interface has no IPv6 address).

A HUGE thank you for taking the time to point out the relevant parts in the documentation and explain them.

Bart

@mathomas3

Timings Name server Query time 127.0.0.1 No response 192.168.1.1 No response

That sure doesn't look normal..

@randombits I have not looked into what Pis do - and would guess depends on what OS your actually running on them. But its possible it could/should also send out a gratuitous arp.

This is basically the device just telling the network on its own, hey if your looking for IP address x.x.x.x - that is me, here is my mac.

This should update any cache..

But sure arp cache should be something you should be aware of when you swap in the other device, that if you have any issues talking to it - make sure to check the cache on the device trying to talk to it, that its cache is not pointing the first devices mac.

@techvic said in DynDNS not updating IP by itself but only with "force update":

but in that scenario the DynDNS is not updated even though I have the entry in the log that claims it updates the DynDNS.

That's why I was asking for what was shown after the line :

909cc90f-25d8-48ca-b1a4-941036a87525-image.png

When using verbose mode (you are) :

cb28d7c4-e023-4b19-b8c6-ed60f681d584-image.png

the answer coming from the dyndns service of that https request will get shown.
That answer also proofs that the dyndns servcie was contacted.
These are a bunch of "Response Header:" and "Response Data:" lines.

In general that's not a known issue. Pretty much everyone here at Netgate runs with a private domain entry for our company domain and things hum along as usual.

unbound can get cranky sometimes if it is trying to reach a specific upstream server and it doesn't respond. Keep an eye on Status > DNS Resolver entries when it works vs when it doesn't work. You can get the same output from the shell with:

: unbound-control -c /var/unbound/unbound.conf dump_infra

Odds are when it stops responding there is an entry in there for a server that has also stopped responding. Restarting unbound clears all that knowledge and forces it to try again. You could also try manually flushing things for that domain (or all domains) to see if that's sufficient to make it try again:

: unbound-control -c /var/unbound/unbound.conf flush_zone foo.com

There are some other similar commands to try listed in the docs:

https://docs.netgate.com/pfsense/en/latest/services/dns/resolver-cli.html

figured it out, there was an old dhcp reservation on one of the carp routers that were not synchrnoised.