Dynamic DNS not working reliably

Bob.Dig

I encountered this now a few times. Dynamic DNS is not working.

At 1:14 AM I got an email from a web service, that my server is not reachable.
Now at 8:30 AM I look at my pfSense 2.4.5-RELEASE-p1 and it shows the following:

When I go to every Dynamic DNS Clients and press the "safe & force update"-button, one by one becomes green again. Also notice, it is not just cloudflare but also HE.

But sometimes (or most of the time?) it does work automatically.
(In my case, pfSense has to do an external lookup, which it does automatically, because my ISP does 1:1 NAT.)

JeGr

Hey Bob :)

Are you using DynDNS behind another router? I'd guess that pfsense didn't get the "reconnection" of the router in front of it hence has no reason to "renew" the dyndns IP? As you wrote your ISP does 1:1 NAT I guessed there's a router in front that has the external IP rather then pfs itself?

Greets
\jens

Gertjan

@Bob-Dig said in Dynamic DNS not working reliably:

"safe & force update"-button

No way.
The good method is :

I look in the logs, found out why the update wan't happening, and corrected it.

What pfSense does, is executong a http request for

that should show just a simple html reply with your IP.
You can test so with a browser on a device on on your LAN. That should work.

The logs tell the rest.

JeGr

@Gertjan that's right, all of it, but if pfSense doesn't get "notified" of a new IP (e.g. ISP router in front of it - so rc.newwanip won't get triggered), it won't renew the IP itself up until the daily refresh will happen at 6am (via cron). So if he has another system in front of pfSense AND got a new IP sometimes through the day it won't get refreshed until the next morning.

Gertjan

True :

this is more some kind of save fail net. Ones a day, a check is forced.

A WAN IP change also triggers a DynDNS check/update - but look at that file : it does far more.
unbound is restarted - OpenVPN is signalled, etc. So, the problem extends farther the only DynDNS.

Btw : check

ps ax | grep 'dpinger'

when a gateway event arrives, /etc/rc.gateway is called. And then one kicks DynDNS for the gateway ....

I've myself a typical pfSense after ISP router, and my WAN is is thus RFC1918 -using DHCP. I could even set it static, my DynDNS is updating faster == some what signalled (by dpinger ?) within a 5 minutes basis ? I actually never measured the delay.
I'll do some test @home, where my WAN (ISP router) IP actually does change every week or so. I'm pretty sure the logs will show that that event doesn't goes by unnoticed.

Bob.Dig

@JeGr said in Dynamic DNS not working reliably:

Hey Bob :)

Hey Jens! Btw. StatusCake is working great

So there is no router in front, at least on my side.

And second, why is the widget already showing, that there is a problem (red ip) but nothing is done by pfSense?

And third, if it is not a bug, what can I do to fix it or have a better solution for that problem? Looking at logs (which log?) probably wouldn't help it any. Can't remember having that problem some months ago.

Bob.Dig

@Gertjan said in Dynamic DNS not working reliably:

@Bob-Dig said in Dynamic DNS not working reliably:

"safe & force update"-button

No way.
The good method is :

I look in the logs, found out why the update wan't happening, and corrected it.

Ok, you are now blocked for ever, silly french man. I will never read your reply again. Don't comment on my posts!

JeGr

@Bob-Dig said in Dynamic DNS not working reliably:

Ok, you are now blocked for ever, silly french man. I will never read your reply again. Don't comment on my posts!

Why? He wasn't really wrong.

Hey Jens! Btw. StatusCake is working good

Glad to read!

So there is no router in front, at least on my side.

OK so that's modem etc. on your WAN side and you have the public IP on your WAN interface directly, right?

And second, why is the widget already showing, that there is a problem (red ip) but nothing is done by pfSense?

Don't confuse display and action. It shows red as it is checked with a live call in the widget where it is displayed to show problems or out of date IPs. That works correctly and is obvious in your case. That has nothing to do with the rc.newwanip or rc.dyndns.update not running or not running correctly so Gertjan is right in that, that at a given time your WAN IP changed and THAT has to be in the logs somewhere (or it's gone too lang already, then you should perhaps increase log size). But that interface action IS happening in the logs and if there is a problem with updating dyndns at this point, the errors are to find there, too.

All I can think of is perhaps a problem when your WAN is dialed in again and e.g. isn't correctly connected yet but the update job tries to run and can't resolve checkip.dyndns.org correctly. Or the address changes again later. Etc. etc. But the correct answer can only be found in the logs when the corresponding rc.<script> is triggered and the dyndns update ran. So Gertjan is right on that - without skimming through the logs it'll be hard to say what the problem is.

Gertjan

What, amongst other, you do not seem to know :
If you Safe Force update a DynDNS setting, you are risking that these blacklist your updates.
Some of them explain why they act like that, it's understandable (ones understood ^^).
Example : A third update on the same day for he.net will block you, which can lead to your IPv6 tunnel going down.

Also : pressing the update button doesn't tell you *- and you us, why things are not working.
( the logs do ...)

Btw : Not really important, but I'm not French at all.

JeGr

Also: language, please! (@Bob-Dig) No need to get angry or twisted over "text" without exactly knowing the real intentions behind it. And @Gertjan isn't really known as spammy or angry-sh*t-poster at all :)

So be kind - rewind :)

Edit: also he's right, he-net is fast on the block buzzer if you force-trying to change the ip if it hasn't changed in the past.

Bob.Dig

@JeGr said in Dynamic DNS not working reliably:

Why? He wasn't really wrong.

But he es no help at all and that was not the first time, so he can write crap elsewhere.

OK so that's modem etc. on your WAN side and you have the public IP on your WAN interface directly, right?

Sure, but again, my ISP is doing 1:1 NAT and I have a CG-NAT-Address at WAN, not my public IP. But that was never a problem for pfSense, it always uses that third party to determine the IP.

So what log is of interest?

So be kind - rewind :)

No, he had is chance.
And reading the logs is always correct, but not helpful to an Anfaenger.

JeGr

@Bob-Dig said in Dynamic DNS not working reliably:

And reading the logs is always correct, but not helpful to an Anfaenger.

Which he can't know and - again - was neither unfriendly nor wrong, simply stating facts. And as you posted no logs, it's hard to say what the problem is anyway - that's what he was telling all along and it's right.

So rookie or not, no reason to be that angry as there was no malintent.

So what log is of interest?

General log is where you can find those events. Filter for "/rc.dydnsn.update" or "/rc.newwanip" for example. You can also search/filter for your current IP and check when the last update happened. That should find some lines like that:

And reading the logs is always correct, but not helpful to an Anfaenger.

It is actually the best help. Especially rookies tend to oversee things in the logs that clearly state the error or where the problem originates. So checking the logs is no ill advice as is "reinstalling" for example. The later one is often given and especially rookies or newbies tend to frown on that with "what's that for crappy advice, nonsense, etc. etc." forgetting, that a) reinstall is really really fast and easy to do (especially with config file recovery it's a matter of ~5-15min tops) and b) one can then rule out any problems with updates going haywire or bad installations/bad blocks (not HDD/SSD going bad but hey). So both are pretty standard things one has to learn to work with.

It has a reason that e.g. in my workshops, trainings or on-site-work with the customer, the problem analysis chapter always
includes "reading, working with and understanding log files".

So even if you choose to ignore him - that's your thing - but no unnecessary hostilities please.

Bob.Dig

@JeGr said in Dynamic DNS not working reliably:

Which he can't know

He knew already.

So I hope this is the important part (/rc.), tried to get rid of unnecessary lines with notepad++, as good as a noob could. But it will proably solve nothing for me anyway. My approach is more "reporting" and let more taletented people solve or ignore it.

Jul 22 00:06:49 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.
Jul 22 00:06:49 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use OPT6_VPNV6.
Jul 22 00:08:29 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use OPT6_VPNV6.
Jul 22 00:09:01 pfSense php-fpm: /rc.newwanip: rc.newwanip: Info: starting on ovpnc2.
Jul 22 00:09:01 pfSense php-fpm: /rc.newwanip: rc.newwanip: on (IP address: 10.8.0.13) (interface: OPT7[opt7]) (real interface: ovpnc2).
Jul 22 00:09:03 pfSense php-fpm: /rc.newwanip: Removing static route for monitor fe80::201:5cff:fea4:ca46 and adding a new route through fe80::201:5cff:fea4:ca46%igb0
Jul 22 00:09:05 pfSense php-fpm: /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.0.4.
Jul 22 00:09:06 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.
Jul 22 00:09:10 pfSense php-fpm: /rc.newwanip: Creating rrd update script
Jul 22 00:09:12 pfSense php-fpm: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.0.4 ->  10.8.0.13 - Restarting packages.
Jul 22 00:09:13 pfSense php-fpm: /rc.start_packages: Restarting/Starting all packages.
Jul 22 00:09:18 pfSense php-fpm: /rc.newwanip: rc.newwanip: Info: starting on ovpnc3.
Jul 22 00:09:18 pfSense php-fpm: /rc.newwanip: rc.newwanip: on (IP address: 10.8.0.8) (interface: OPT8[opt8]) (real interface: ovpnc3).
Jul 22 00:09:19 pfSense php-fpm: /rc.newwanip: Removing static route for monitor fe80::201:5cff:fea4:ca46 and adding a new route through fe80::201:5cff:fea4:ca46%igb0
Jul 22 00:09:22 pfSense php-fpm: /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.0.7.
Jul 22 00:09:23 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.
Jul 22 00:09:26 pfSense php-fpm: /rc.newwanip: Creating rrd update script
Jul 22 00:09:28 pfSense php-fpm: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.0.7 ->  10.8.0.8 - Restarting packages.
Jul 22 00:09:29 pfSense php-fpm: /rc.start_packages: Restarting/Starting all packages.
Jul 22 00:17:00 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use OPT6_VPNV6.
Jul 22 00:26:46 pfSense php-fpm: /rc.newwanip: rc.newwanip: Info: starting on ovpnc3.
Jul 22 00:26:46 pfSense php-fpm: /rc.newwanip: rc.newwanip: on (IP address: 10.8.3.10) (interface: OPT8[opt8]) (real interface: ovpnc3).
Jul 22 00:26:48 pfSense php-fpm: /rc.newwanip: Removing static route for monitor fe80::201:5cff:fea4:ca46 and adding a new route through fe80::201:5cff:fea4:ca46%igb0
Jul 22 00:26:50 pfSense php-fpm: /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.0.8.
Jul 22 00:26:51 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.
Jul 22 00:26:55 pfSense php-fpm: /rc.newwanip: Creating rrd update script
Jul 22 00:26:57 pfSense php-fpm: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.0.8 ->  10.8.3.10 - Restarting packages.
Jul 22 00:26:58 pfSense php-fpm: /rc.start_packages: Restarting/Starting all packages.
Jul 22 00:28:44 pfSense php-fpm: /rc.newwanip: rc.newwanip: Info: starting on ovpnc4.
Jul 22 00:28:44 pfSense php-fpm: /rc.newwanip: rc.newwanip: on (IP address: 10.8.3.2) (interface: OPT9[opt9]) (real interface: ovpnc4).
Jul 22 00:28:46 pfSense php-fpm: /rc.newwanip: Removing static route for monitor fe80::201:5cff:fea4:ca46 and adding a new route through fe80::201:5cff:fea4:ca46%igb0
Jul 22 00:28:48 pfSense php-fpm: /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.0.24.
Jul 22 00:28:49 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.
Jul 22 00:28:53 pfSense php-fpm: /rc.newwanip: Creating rrd update script
Jul 22 00:28:55 pfSense php-fpm: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.0.24 ->  10.8.3.2 - Restarting packages.
Jul 22 00:28:56 pfSense php-fpm: /rc.start_packages: Restarting/Starting all packages.
Jul 22 00:29:19 pfSense php-fpm: /rc.newwanip: rc.newwanip: Info: starting on ovpnc2.
Jul 22 00:29:19 pfSense php-fpm: /rc.newwanip: rc.newwanip: on (IP address: 10.8.0.4) (interface: OPT7[opt7]) (real interface: ovpnc2).
Jul 22 00:29:21 pfSense php-fpm: /rc.newwanip: Removing static route for monitor fe80::201:5cff:fea4:ca46 and adding a new route through fe80::201:5cff:fea4:ca46%igb0
Jul 22 00:29:23 pfSense php-fpm: /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.0.13.
Jul 22 00:29:24 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.
Jul 22 00:29:27 pfSense php-fpm: /rc.newwanip: Creating rrd update script
Jul 22 00:29:29 pfSense php-fpm: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.0.13 ->  10.8.0.4 - Restarting packages.
Jul 22 00:29:30 pfSense php-fpm: /rc.start_packages: Restarting/Starting all packages.
Jul 22 01:37:25 pfSense php-fpm: /rc.newwanip: rc.newwanip: Info: starting on ovpnc3.
Jul 22 01:37:25 pfSense php-fpm: /rc.newwanip: rc.newwanip: on (IP address: 10.8.1.8) (interface: OPT8[opt8]) (real interface: ovpnc3).
Jul 22 01:37:27 pfSense php-fpm: /rc.newwanip: Removing static route for monitor fe80::201:5cff:fea4:ca46 and adding a new route through fe80::201:5cff:fea4:ca46%igb0
Jul 22 01:37:27 pfSense php-fpm: /rc.newwanip: The command '/usr/local/bin/dpinger -S -r 0 -i OPT7_VPNV4 -B 10.8.0.4 -p /var/run/dpinger_OPT7_VPNV4~10.8.0.4~10.8.0.4.pid -u /var/run/dpinger_OPT7_VPNV4~10.8.0.4~10.8.0.4.sock -C "/etc/rc.gateway_alarm" -d 1 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20  10.8.0.4 >/dev/null' returned exit code '1', the output was '' 
Jul 22 01:37:27 pfSense php-fpm: /rc.newwanip: Error starting gateway monitor for OPT7_VPNV4
Jul 22 01:37:29 pfSense php-fpm: /rc.newwanip: rc.newwanip: Info: starting on ovpnc2.
Jul 22 01:37:29 pfSense php-fpm: /rc.newwanip: rc.newwanip: on (IP address: 10.8.0.3) (interface: OPT7[opt7]) (real interface: ovpnc2).
Jul 22 01:37:29 pfSense php-fpm: /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.3.10.
Jul 22 01:37:30 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.
Jul 22 01:37:32 pfSense php-fpm: /rc.newwanip: Removing static route for monitor fe80::201:5cff:fea4:ca46 and adding a new route through fe80::201:5cff:fea4:ca46%igb0
Jul 22 01:37:34 pfSense php-fpm: /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.0.4.
Jul 22 01:37:34 pfSense php-fpm: /rc.newwanip: Creating rrd update script
Jul 22 01:37:35 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.
Jul 22 01:37:36 pfSense php-fpm: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.3.10 ->  10.8.1.8 - Restarting packages.
Jul 22 01:37:37 pfSense php-fpm: /rc.start_packages: Restarting/Starting all packages.
Jul 22 01:37:39 pfSense php-fpm: /rc.newwanip: Creating rrd update script
Jul 22 01:37:41 pfSense php-fpm: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.0.4 ->  10.8.0.3 - Restarting packages.
Jul 22 01:37:42 pfSense php-fpm: /rc.start_packages: Restarting/Starting all packages.
Jul 22 01:40:22 pfSense php-fpm: /rc.newwanip: rc.newwanip: Info: starting on ovpnc4.
Jul 22 01:40:22 pfSense php-fpm: /rc.newwanip: rc.newwanip: on (IP address: 10.8.1.6) (interface: OPT9[opt9]) (real interface: ovpnc4).
Jul 22 01:40:24 pfSense php-fpm: /rc.newwanip: Removing static route for monitor fe80::201:5cff:fea4:ca46 and adding a new route through fe80::201:5cff:fea4:ca46%igb0
Jul 22 01:40:26 pfSense php-fpm: /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.3.2.
Jul 22 01:40:28 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.
Jul 22 01:40:31 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use OPT6_VPNV6.
Jul 22 01:40:32 pfSense php-fpm: /rc.newwanip: Creating rrd update script
Jul 22 01:40:34 pfSense php-fpm: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.3.2 ->  10.8.1.6 - Restarting packages.
Jul 22 01:40:35 pfSense php-fpm: /rc.start_packages: Restarting/Starting all packages.
Jul 22 01:40:40 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use OPT6_VPNV6.
Jul 22 01:45:24 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use OPT6_VPNV6.
Jul 22 01:46:48 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use OPT6_VPNV6.
Jul 22 01:48:44 pfSense php-fpm: /rc.newwanip: rc.newwanip: Info: starting on ovpnc2.
Jul 22 01:48:44 pfSense php-fpm: /rc.newwanip: rc.newwanip: on (IP address: 10.8.1.13) (interface: OPT7[opt7]) (real interface: ovpnc2).
Jul 22 01:48:46 pfSense php-fpm: /rc.newwanip: Removing static route for monitor fe80::201:5cff:fea4:ca46 and adding a new route through fe80::201:5cff:fea4:ca46%igb0
Jul 22 01:48:46 pfSense php-fpm[4089]: /rc.filter_configure_sync: dpinger: No dpinger session running for gateway OPT10_VPNV4
Jul 22 01:48:46 pfSense php-fpm[4089]: /rc.filter_configure_sync: dpinger: No dpinger session running for gateway OPT9_VPNV4
Jul 22 01:48:46 pfSense php-fpm[4089]: /rc.filter_configure_sync: dpinger: No dpinger session running for gateway WAN_DHCP
Jul 22 01:48:46 pfSense php-fpm: /rc.newwanip: The command '/usr/local/bin/dpinger -S -r 0 -i OPT9_VPNV4 -B 10.8.1.6 -p /var/run/dpinger_OPT9_VPNV4~10.8.1.6~10.8.3.4.pid -u /var/run/dpinger_OPT9_VPNV4~10.8.1.6~10.8.3.4.sock -C "/etc/rc.gateway_alarm" -d 1 -s 500 -l 2000 -t 60000 -A 1000 -D 500 -L 20  10.8.3.4 >/dev/null' returned exit code '1', the output was '' 
Jul 22 01:48:46 pfSense php-fpm: /rc.newwanip: Error starting gateway monitor for OPT9_VPNV4
Jul 22 01:48:46 pfSense php-fpm: /rc.newwanip: rc.newwanip: Info: starting on ovpnc4.
Jul 22 01:48:46 pfSense php-fpm: /rc.newwanip: rc.newwanip: on (IP address: 10.8.3.4) (interface: OPT9[opt9]) (real interface: ovpnc4).
Jul 22 01:48:48 pfSense php-fpm: /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.0.3.
Jul 22 01:48:49 pfSense php-fpm: /rc.newwanip: Removing static route for monitor fe80::201:5cff:fea4:ca46 and adding a new route through fe80::201:5cff:fea4:ca46%igb0
Jul 22 01:48:49 pfSense php-fpm[4089]: /rc.openvpn: dpinger: No dpinger session running for gateway OPT6_VPNV4
Jul 22 01:48:49 pfSense php-fpm[4089]: /rc.openvpn: dpinger: No dpinger session running for gateway OPT8_VPNV4
Jul 22 01:48:49 pfSense php-fpm: /rc.filter_configure_sync: dpinger: No dpinger session running for gateway WAN_DHCP
Jul 22 01:48:49 pfSense php-fpm[4089]: /rc.openvpn: dpinger: No dpinger session running for gateway WAN_DHCP
Jul 22 01:48:49 pfSense php-fpm[4089]: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.
Jul 22 01:48:51 pfSense php-fpm: /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.1.6.
Jul 22 01:48:52 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.
Jul 22 01:48:54 pfSense php-fpm: /rc.newwanip: The command '/usr/local/sbin/unbound -c /var/unbound/unbound.conf' returned exit code '1', the output was '[1595375334] unbound[21504:0] error: bind: address already in use [1595375334] unbound[21504:0] fatal error: could not open ports' 
Jul 22 01:48:54 pfSense php-fpm: /rc.newwanip: Creating rrd update script
Jul 22 01:48:57 pfSense php-fpm: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.0.3 ->  10.8.1.13 - Restarting packages.
Jul 22 01:48:57 pfSense php-fpm: /rc.newwanip: Creating rrd update script
Jul 22 01:48:58 pfSense php-fpm: /rc.start_packages: Restarting/Starting all packages.
Jul 22 01:48:59 pfSense php-fpm: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.1.6 ->  10.8.3.4 - Restarting packages.
Jul 22 01:49:00 pfSense php-fpm: /rc.start_packages: Restarting/Starting all packages.
Jul 22 01:51:41 pfSense php-fpm: /rc.newwanip: rc.newwanip: Info: starting on ovpnc3.
Jul 22 01:51:41 pfSense php-fpm: /rc.newwanip: rc.newwanip: on (IP address: 10.8.3.3) (interface: OPT8[opt8]) (real interface: ovpnc3).
Jul 22 01:51:43 pfSense php-fpm: /rc.newwanip: Removing static route for monitor fe80::201:5cff:fea4:ca46 and adding a new route through fe80::201:5cff:fea4:ca46%igb0
Jul 22 01:51:45 pfSense php-fpm: /rc.newwanip: IP Address has changed, killing states on former IP Address 10.8.1.8.
Jul 22 01:51:46 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.
Jul 22 01:51:50 pfSense php-fpm: /rc.newwanip: Creating rrd update script
Jul 22 01:51:52 pfSense php-fpm: /rc.newwanip: pfSense package system has detected an IP change or dynamic WAN reconnection - 10.8.1.8 ->  10.8.3.3 - Restarting packages.
Jul 22 01:51:53 pfSense php-fpm: /rc.start_packages: Restarting/Starting all packages.
Jul 22 04:39:44 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use OPT6_VPNV6.
Jul 22 04:41:14 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use OPT6_VPNV6.
Jul 22 08:38:40 pfSense php-fpm: /rc.openvpn: OpenVPN: One or more OpenVPN tunnel endpoints may have changed its IP. Reloading endpoints that may use TUNNELBROKERNET_TUNNELV6.

Btw. my WAN-addresses always begins with 100.65.

JeGr

@Bob-Dig said in Dynamic DNS not working reliably:

Btw. my WAN-addresses always begins with 100.65

Which means you are behind a CGN, I see.

But I don't see even one mention in the logs concerning the WAN IP (100.x). Are there any? There should have been at least one about getting a new WAN IP if your WAN IP changed. I'm missing a "newwanip" event on WAN, not on OVPNx.
Also no rc.dyndns.update? At all? There should be one forced daily so that should pop up at least?

Bob.Dig

@JeGr Probably the wrong filter.

At Jul 22 08:37:41, it was me doing it manually.

JeGr

Sorry can't download it, the site switches from https to http and back and in the end there's a 404.

Bob.Dig

@JeGr You have to wait 15 seconds, then the download link appears. At least, working here.

JeGr

Some Hosts of that "filehoster" have bad/invalid TLS certs and broken chains. Wouldn't trust such a setup but anyways seems I got one that actually works now that could serve the file.

I see multiple events popping up in that log that could be related to the error, but those are the ones sticking out:

Jul 22 01:01:16 pfSense php-cgi: rc.dyndns.update: phpDynDNS (xxxxxx): PAYLOAD: -ERROR: IP is not ICMP pingable.  Please make sure ICMP is not blocked.  If you are blocking ICMP, please allow <ip> through your firewall.

That one is IMHO related to HE.NET and as it is followed by "unknown response" isn't a good sign. It seems you're not allowing ICMP or they can't reach you because you're behind CGN - I'm not sure in that case. As it's working manually later on it could be that your IP change / CGN is related to that.

The Cloudflare ones were updated to a public IP 86.x.y.z successfully. Still could not find any mention about an IP change upstream (100.xy IP as you said), so pfSense itself saw/sees NO change in WAN IP that I can find in the logs.

Your manual update later changed the IP to a 82.x.y.z IP (from the 86 it detected at 1am), so in the meantime it seems your public IP changed (again).

For me that seems like your connection is stable but your provider just changes your externally mapped 1:1 IP to something they like when they like without actually terminating your connection? If that's the case, that's no way pfSense could ever "see" that problem as it is not aware that anything changed upstream and only the 1am cron job of "manually" running the dyndns script does the check but as they seem to change to IP again after a few hours it's nothing it can do.

I'd ask my provider about that and how (the hell) they actually map a public IP to you as it seems pretty random to me. That's the "beauty" of CGN at work as it seems.
Perhaps you'd be better of OpenVPN'ing a small VPS in the cloud with a static IP4&IP6/64 and use that as your static IP-set as it would be far more reliable than a DynDNS IP from an ISP doing CGN, IPFT and other means to ease the use of IP4s.

Bob.Dig

@JeGr I love my dynamic IP, so no way I would go with a static one, although I get your professional opinion on that.

HE is allowed to ping me.

But also, the cron job at 6 AM (?) didn't do anything it seems. At least I can't see it in the logs.

If everything works as planed, I will get internet from the pink T next month.
Then I will have cable and dsl at the same time, but going on, I will get rid of cable.

JeGr

@Bob-Dig said in Dynamic DNS not working reliably:

But also, the cron job at 6 AM (?) didn't do anything it seems. At least I can't see it in the logs.

Default one is at 1am. I reconfigured mine to 6am to be nearer to my "activity time".
So that's the default daily cron you see in your logs working as intended.

I love my dynamic IP, so no way I would go with a static one

Nothing to say to that. They serve no purpose at all as to only make tech life harder and make ISPs think up fucked up solutions to a problem of their own making. If I could I'd get one in a heartbeat as there's no real reason not to have one. If I don't want to show it? VPNs are everywhere. Privacy? No real reason. And with self-hosted services like yours stupid to work around.

But hey to each its own. You can have mine, too if I get a static one instead!