@gertjan Thanks a lot for the detailed feedback. I will try that, as soon as I can. I have now experienced the same problem on a total other network, so this points at MacOs network as the problem. Will test and get back. Thanks again

@gertjan said in Batch-force DynDNS updates for all accounts?: Or execute /etc/rc.dyndns.update all Thanks man, that is a life saver! @gertjan said in Batch-force DynDNS updates for all accounts?: Also : this is a must-have : install the pfSense cron package. Yeah, I had done that already. @gertjan said in Batch-force DynDNS updates for all accounts?: You see that one minute past every day the same script is used : Add (do not modify the cron entry that already exists) another one : Well, I had modified the original entry so that it would check every fifteen minutes, but I had made a mistake to the effect that it only checked every fifteen minutes during the first hour of the day. You example helped me identify this mistake. Hopefully the updating will now take place more regularly. In that context: Do you happen to know whether the client checks, if the IP has actually changed before it posts the IP address to the nameservers? Or will it always post the current IP no matter whether this is necessary or not? Thanks again, you saved my day!

My last post should read version 2.5.1 and 2.6.0 (not 4.5.1 and 4.6.0) I kept at this and finally figured out a way to make it work. I had to add this to Domain Overrides: in-addr.arpa 8.8.8.8 Because we use Active Directory at some locations, I may also need to check "Do not forward private reverse lookups" or add overrides for the local IPs we use for AD. I would love to know why this fixes the problem. What IPs is pfSense doing reverse lookups on for the Update and ACB features?

@sensewolf said in Dynamic DNS update failing every couple of days: How can I debug this? By setting : [image: 1667288986704-93ea0a15-1e20-4aa2-8a69-3ace97791b4d-image.png] and now the resulting logs will be more verbose. Normally, when you set up a dyndns entry, you have to select an interface : [image: 1667289750703-7d36557b-eeba-4c5b-923f-42ab3e41c0cf-image.png] so, when pfsense tests this interface for the 'real' WAN' ip, it uses [image: 1667289815751-3015d53d-4dd0-404d-959a-698d8b2adcde-image.png] http://checkip.dyndns.org You can 'see' it doing so in the logs. The thing is, I'm a 'solo WAN guy' so I don't know what it is to have more then one WAN. As you have to select a WAN type interface in the dyndns settings, it should use the right one to use. But when you group them up : what happens ??

Thank you for the reply, greatly appreciated.

It seems that pfsense has a BIND package. I might see how I can get BIND running with views and use BIND as a forward only DNS server with a pair of views.

@gertjan Thank you my friend. with openvpn remote access tunnels, I'm using the default "OpenVPN" ta for firewall rules, so i don't have to assign interfaces for each remote access tunnel. I have to assign interfaces for site to site only. I get the DNS working for remote clients by pushing a DNS server the IP of pfsense. Assuming that the firewall can perform the forwarding succesfully, remote users have a routing to LAN, but not DNS or internet gateway. (We have used VPN only for remote access to servers). So under advanced client settings in Open VPN Server configuration, i just push a DNS server, the pfsense address, like below: [image: 1667224646486-b8472410-f012-4133-a21e-54860390c989-image.png] Simple thing but i didn't knew that , because i never needed that until today.

@munchie The OP was using earlier pfSense version. What is your version ? What does your /var/unbound/root.key contain ? During boot, look at the the console, any non normal messages ? Btw : this root.key is the DNSSEC root key. It can change upstream, that that would be extremely rare. It is updated regularly, and the time stamps in the file reflect this. pfSense should use the exact time. This is mandatory, for DNSSEC to work.

@nan0tech this thread is quite old.. the no AAAA thing is now here for easy consumption [image: 1667063671148-noaaaa.jpg] Per @bruor comment.. I find pictures are easier for some users.

@zinder a 60 second TTL on their nameservers.. That is nuts!!! And then you can see doing a directed query to the server at 1 point works, and then another time fails with the server responding with error for its own domain its authoritative for. Maybe they are working through a problem? But as you can see from that link, even when working their dnssec has issues.. If you know someone that manages that dns for them.. Yeah have them check out that link.. If your not going to do dnssec correctly - then you shouldn't be doing it.. edit: just checked on this - both of their NS are failing right now. 10/29 5:45 CDT

It appears that Apple has added adaptive DNS to Ventura. I'm seeing these queries on my network since upgrading two Mac's to Ventura.

Blarg. I noticed there was a patch file being applied to this stuff and thought I would poke around a little. Turns out if I modify /etc/inc/dyndns.class a little I can get the "googledomains" working again. I already have the "patchfile" package added from Package Manager, so I'm going to add my own custom patchfile, and keep using googledomains.. until the update breaks it. existing patchfile /usr/local/pkg/patches/b5360f49fb3c1fdc36ebf13c20b68d4ff1e15fe6.patch My patchfile https://gist.github.com/therevoman/cc986a390bb08255d4119903f734f22d : diff -u /home/backup/etc/inc/dyndns.class /etc/inc/dyndns.class --- a/src/etc/inc/dyndns.class 2022-10-21 22:11:05.836183000 +0000 +++ b/src/etc/inc/dyndns.class 2022-10-26 19:13:32.756072000 +0000 @@ -1209,11 +1209,11 @@ $post_data['hostname'] = $this->_dnsHost; $post_data['myip'] = $this->_dnsIP; $post_data['offline'] = 'no'; $server = "https://domains.google.com/nic/update"; $server = "https://domains.google.com/nic/update?hostname=" . $this->_dnsHost; $port = ""; curl_setopt($ch, CURLOPT_URL, 'https://domains.google.com/nic/update'); curl_setopt($ch, CURLOPT_URL, 'https://domains.google.com/nic/update?hostname=' . $this->_dnsHost); curl_setopt($ch, CURLOPT_USERPWD, $this->_dnsUser . ':' . $this->_dnsPass); curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data); #curl_setopt($ch, CURLOPT_POSTFIELDS, $post_data); break; case 'dnsmadeeasy': $needsIP = TRUE;

@paulg-79 If your running the VPN on your computer it has probably nothing to do with pfSense. I assume, the VPN server is providing a DNS server, but investigate it to get sure. If it's a Windows OS run "ipconfig /all", while the VPN is up, and check if there is a DNS server shown for the virtual VPN network adapter.

@thierry-1 Wait .... Because snort has nothing to do on the 'hot' side (WAN) as all traffic is already blocked in the first place, it decided to focus on your side (LAN) and makes your live miserable by blocking traffic from the firewall itself ?? What was the reason you installed snort in the first place ? To do what ? But ok, you made a good choice : remove (snort) as much non essential stuff on your firewall : things work way better, less maintenance, less can go wrong. Use only what you can manage

@viragomann said in External router not assigned IP, but connected devices are: @skikibobski I don't know this router. I said, maybe there is an option to allow outside access. If not, you can NAT the access on pfSense. To do so, you have to add an outbound NAT rule for the router. Firewall > NAT > Outbound Switch to hybrid mode and save this first. Then add a rule: interface: that one the router is connected to source: any (or a specific subnet) destination: select "Network" and enter the routers IP and /32 mask You may also state the WebGUI port to limit the rule just for this purpose translation: interface address That did it! NAT rule on pfSense fixed it, I now have access to both webui via ethernet. Thanks so much for your very quick help!

@johnpoz said in iPhone: Privacy Warning: @cloudified here is the warning the OP was talking about. https://developer.apple.com/forums/thread/661116 I just read the release notes, so I didn't see this forum post until now, so thanks for sharing it.

@luckman212 infra cache is only going to be there for so long. Defaults to 15 minutes I believe. So yeah if you haven't asked a specific NS your forwarding to anything in a while, it would most likely fall out of the cache.

@sdm900 I can confirm that this bug still exists with version 2.6.0-RELEASE (amd64). The supplied fix appears to allow DHCP to continue running after entering in denied clients with the "ignore" option selected.