@viktor_g Perfect - learned something new and fixed the issue!

I have no idea why your seeing those - but has nothing to do with acme updating a dns record.. SOA of whatever domain your doing isn't going to be cloudflare-dns.com nor is it going to dns.google, etc.. Many of those queries your blocking out what the actual fqdn was.. and you local domain... And why and hell would you hide your rfc1918 address 172.20.x.x ? anything using the api for cloudflare would be talking to api.cloudflare.com, godaddy would be either api.ote-godaddy.com or api.godaddy.com Its quite possible whatever your doing with trying to filter is just breaking dns in general.. But if your updating anything with the apis of cloudflare or godaddy it sure would be trying to resolve the doh fqdn.. edit: btw I have domains with cloudflare, and use acme certs for those domains.. I have no issues renewing them.. And I specifically block doh domains by resolving them to a specific rfc1918 address, so I can see if any clients try and resolve them and access them.. ;; QUESTION SECTION: ;cloudflare-dns.com. IN A ;; ANSWER SECTION: cloudflare-dns.com. 120 IN A 172.19.19.19 So if acme needed to talk to cloudflare-dns.com for some reason it wouldn't be able to.. I also have their real IPs blocked.. the fqdn or IP of cloudflare-dns.com would not be used in renewing a cert via clouldflare and acme.. It just wouldn't - they are not related to the api, and or anything to do with actually resolving whatever you domain is.

@skilledinept It wasn't all that difficult putting the leases into a PowerShell script now that they're super tidy. :) Still, pfSense UI, which is rather clunky and slow beats from the oldest MMC, to IPAM, SCCM to the newest W Admin Center. PowerShell, surprisingly, the best because you can wipe all and load from a text file UNIX-style all within a VS Code window, RDS is still needed though. I thought it was going to be another couple of days copying MAC addresses. :/. It's mind blowing that this OS is a serious product. If anyone knows how to fix it though, I'd still like to attempt that. :)

I suspect this is the same issue I reported here which has not been resolved as 21.05.1: Every Reboot Requires Restart of DNS Resolver Do a reboot and I bet you will need to follow it with an unbound restart to restore DNS resolution. Let us know… Peter

@b_chris There are a lot of things different in IPv6, compared to IPv4. One of these is having multiple addresses on the same interface. This was also possible in IPv4, with aliases, but it wasn't common. With pfsense, on the RA page, you can add several prefixes, if you wish.

From the authoritative nameserver, resolve vs forward. This is what pfsense does out of the box, it resolves vs forwards. dnssec is how you can know the dns has not been manipulated because the records have been signed by the owners of the domain.. Not all domains do this - but they should. https://dictionary.cambridge.org/us/dictionary/english/straight-from-the-horse-s-mouth (straight) from the horse's mouth If you hear something (straight) from the horse's mouth, you hear it from the person who has direct personal knowledge of it. https://en.wikipedia.org/wiki/Domain_Name_System_Security_Extensions

why DHCP dishes out no gateway as long as it is without WAN connection Never seen such a thing.. Pfsense out of the box, will hand out its own IP on the interface your running dhcp on.. Unless you have set it up otherwise.. "The default is to use the IP on this interface of the firewall as the gateway. Specify an alternate gateway here if this is not the correct gateway for the network. Type "none" for no gateway assignment." As to why it can do odd stuff with only 1 interface configured - is puts the default antilock out on this interface so you can get to it. How can it hand out dhcp on an interface set for dhcp, etc. So without full details of what you did in what order.. I am just saying that bringing up pfsense with only 1 interface, and then enabling another interface can cause some issues, as it flips the antilock rules and where your actually connected from.. Also - pfsense without dns, the web interface can be slow to respond - maybe took this as not working? All I can say is in the prob 100's of pfsense I have setup - have never seen what your saying is happening.. If there is a lan, and you set its IP and turn on dhcp, it will hand out IPs with the gateway set as its IP on that interface. Unless you edit dhcp to hand out something else.

@kiokoman Thank you for your quick and clear reply! This helped me out a lot, I didn't realize we could add "Send options" in such a way! I haven't managed to get a public IP yet but am getting closer and closer :) Have a great day

@steveits said in Get DHCP IP for OPT1 from LAN: The reason other WAN addresses are needed are so the routers can connect to the Internet, for example to install updates without forcing a failover. If you have only one WAN IP there is a possible workaround with gateway groups to get internet access on the backup node as well. You can create a gw group on both with the CARP VIP as tier 1 and the respective others LAN IP as tier 2. Then set this gw group as default gw. You will have to disable XMLRPC sync of static routes settings. So if the CARP is occupied by the master, the backup node uses the masters LAN for connecting to the internet. Might be a bit tricky, but should work thus far.

Rebuilt the box from scratch with no config restore and all seems to be okay until Pfblocker-ng DEVEL was fully configured with all the block list feeds, shortly after the IP on the LAN interface changed again, this must be a bug? The interface is now showing the IP of "0.0.0.1" on the dashboard page, and "100.64.0.3" in the interface page, however, DHCP is running so that's a bonus. I may try removing all the feeds again to see if the issue stops (I did submit a bug on the main reporting page however it was deleted as a bot..) As a side note, i did export the config and search for "0.0.0.1" to see if it was being set somewhere however no luck finding such line in the config xml file.

https://nlnetlabs.nl/documentation/unbound/unbound.conf/ https://calomel.org/unbound_dns.html

@tiger-0 ??? Do you mean on the LAN side, so that WiFi devices can connect? Or do you mean something on the WAN side? Normally, you just connect the AP to the LAN side. though you may add extra SSIDs via VLAN. Here I have a guest WiFi set up on my AP, using a VLAN, with the main WiFi connected on the native LAN.

I found the issue, apparently it was my nic. It doesn't like Hardware Checksum Offloading. I disabled that and now everything is working.

@gertjan Thank you, I am trying it out right now to see, if the behavior of showing red IPs in the ddns-widget is changing. No more red IPs... will stick with gertjans service for now.

I initially thought you were just referring the root domain server list aka “.” so I just didn’t redirect them. When it comes to SSL certs validation rules always apply. But if you saying the CN is not tied to the domain of the DNS lookup then mitm is no problem with a trusted CA deployment. I just got that impression from what you said above

@_igor_ No worries. I thought I'd reply to my own post with the solution i found hoping it would help someone else out in the future, but jeez that was quick.

@johnpoz gotcha, much appreciated! Implementing this right away ;).