DDNS Client skipped IP update
I've lost connection to my server today only to realize the DDNS did not update the IP although it had changed (and changes daily). The Internet connection worked normally and it was showing the actual IP on the dashboard and the DDNS page had all green "Cached IP" but the green addresses were incorrect/old. This resulted in 6h outage until I realized what was going on. Upon forcing update, everything worked normally. I've been using the same configuration for months and never had this happen before. There's multiple DDNS addresses and they all showed the same. Once I manually updated, all updated to new one. Is this a bug of some sort?
Gertjan last edited by
Your pfSense WAN is the 'WAN' IP ?
With 'WAN' IP I mean, the one pfSense finds using Services / Dynamic DNS / Check IP Services ?
Yes, well I assume, I haven't touched that tab but it's worked unattended for about a year - pfSense is connected directly to Internet - PPPoE directly to WAN port and then pfSense establishes PPPoE connection, the PPPoE interface shows the external IP and it's worked the same before and after, except this one hiccup. I don't know what happened - it's as if it wasn't aware of the IP change.
Check IP Services has one entry and that is http://checkip.dyndns.org. There is no way to open or edit that entry.
Gertjan last edited by
Well, great, you actually answered exactly what I wanted to know. pfSense has access to the 'real' WAN IP without trusting what it seees on it's WAN interface. This way, it will detected a change for sure.
I've been using PPPoE for years myself, as it seems the most logic way to do things : have pfSense 'see' the real WAN IP.
And you're right : if the DDNS didn't work, you experienced something rare. Only the logs at that moment could shed some light on the issue.
I can only suggest that you install the con package.
You will find a line that runs the DDNS one a day ( /usr/bin/nice -n20 /etc/rc.dyndns.update ). Make it run more often so, if problems persist, your WAN IP gets updated faster.
Not a real solution, sorry, can't tell what went wrong.
I did the ISP router to pfSense interface the best I could, took a lot of trial and error to get that PPPoE passthrough working for some reason, but it's been working without issues ever since.
The con I assume is cron; I have installed Cron and the currently configured " /usr/bin/nice -n20 /etc/rc.dyndns.update" line is 1 1 * * *, which is daily? I always assumed it checked the external IP often like a watchdog to prevent anomalies.
I changed it to 1 * * * *, but pfSense updates the address whenever I reconnect the PPPoE connection, that is done separately?
Also which logs should I look at? There no "Related log entries" button in the Services -> Dynamic DNS. Only thing close to it is "DNS Resolver" in the logs but I guess that shouldn't be there. I tried to look at the logs when it happened but I couldn't figure out which log it was.
Also thanks for the reply.
Same issue again today; 3 hours downtime, I've got logs this time.
I'm using free NoIP for DNS.
The state I noticed this in was as follows:
The cached IP under the DynamicDNS service shows current IP address. DNS resolution for the hostname returns old IP address. The NoIP website interface shows the old IP address as entry for the hostname (i.e. not updated). IP check service is set (by default) to http://checkip.dyndns.org.
Cron has been set to run the DNS update every hour, as advised, but this is a moot point since it doesn't actually UPDATE it every hour, it only CHECKS internally every hour and compares it to what it think last set value was and this value is wrong.
When I used the force save & update on the DynamicDNS entry edit, it properly updated the DNS, and everything returned to normal instantly.
NOIP_HOSTNAME - hostname registered on NoIP
NOIP_HOSTNAME_SECOND - second hostname registed on NoIP, not relevant to this, albeit it updated properly, unlike the first one
OLD_IP_ADDRESS - previously assigned WAN IP address
CURRENT_IP_ADDRESS - currently assigned WAN IP address
Here is the interesting part:
Jun 23 10:00:16 php-fpm 88368 /rc.newwanip: phpDynDNS (NOIP_HOSTNAME): (Success) IP address is current, no update performed.
Jun 23 10:00:16 php-fpm 88368 /rc.newwanip: phpDynDNS: updating cache file /conf/dyndns_wannoip-free'NOIP_HOSTNAME'0.cache: CURRENT_IP_ADDRESS
Jun 23 10:00:16 php-fpm 88368 /rc.newwanip: Dynamic DNS noip-free (NOIP_HOSTNAME): CURRENT_IP_ADDRESS extracted from local system.
Jun 23 10:00:16 php-fpm 88368 /rc.newwanip: Dynamic DNS noip-free (NOIP_HOSTNAME): _checkStatus() starting.
Jun 23 10:00:11 php-fpm 88368 /rc.newwanip: Dynamic DNS noip-free (NOIP_HOSTNAME): _update() starting.
Jun 23 10:00:11 php-fpm 88368 /rc.newwanip: DynDns (NOIP_HOSTNAME): Dynamic Dns: cacheIP != wan_ip. Updating. Cached IP: OLD_IP_ADDRESS WAN IP: CURRENT_IP_ADDRESS
I have checked the log from the previous day and the difference is in this line:
"Jun 23 10:00:16 php-fpm 88368 /rc.newwanip: phpDynDNS (NOIP_HOSTNAME): (Success) IP address is current, no update performed."
the previous day says:
"Jun 22 10:00:12 php-fpm 5259 /rc.newwanip: phpDynDNS (NOIP_HOSTNAME): (Success) DNS hostname update successful."
Whole log included.
3rd time it happened...
https://crontab.guru/#1_1___* is at 01:01 of every day
1 * * * * it's at minute 01 of every hour
i don't know why it's happening but if i were in you to test i will delete all the ddns and put them back one at a time and check.
I have cron configured to launch DDNS update every hour, as I have mentioned above, but unfortunately it does not actually go through with the update, unless it thinks the address has changed, it seems to check the IP only once and somehow comes up with incorrect IP, thinks it's up-to-date and none of the 24 additional updates trigger an actual update... What do you suggest?
you can try to delete the cache inside /cf/conf before calling /etc/rc.dyndns.update
for example you can create a script inside /root/updatenoip.sh
#!/bin/sh rm /cf/conf/dyndns_wannoip-free* /etc/rc.dyndns.update
chmod +x /root/updatenoip.sh
than edit crontab
i can't reproduce this, the script is working for me