Update 2.7.2 to 2.8.0 Dynamic DNS not working with Cloudflare
-
Do you only have an IPv6 address there?
I'm using PPPoE over VDSL here and it work fine. There must be something else in play.
-
Is your upstream gateway shown as online?
In 2.8.0 (and 25.03) dyndns update will fail if the gateway is offline.
-
@stephenw10
Nope, it's dual stack (IPv4 and IPv6) -
@stephenw10
It's indeed offline.
I just changed it to unmonitored and, who would have thought, the DynDNS update is working again. -
@djstone
ok, I'll have to correct that statement - IPv6 worked. IPv4 shows "0.0.0.0" as IP. -
@djstone
I think the cause for the IPv4 address not updating might be, that I already did it via another service. Will restart the pppoe connection and see if it comes back to live correctly. -
Ok, so far the gateway status seems to have been the root cause. Thank you for your fast response.
It would be nice, if one checks "verbose" on the Dynamic DNS configuration, to actually receive a verbose ouput or at least a hint to why the update failed.Last thing I see me having to do is dig into the php source code to find the possible causes.
Thanks again. -
Yup I agree. Let me see about adding some debugging there.
-
Thank you @stephenw10. That worked for me also.
-
Is there any news about the problem, or is there a workaround?
-
Trying to follow along, not tried everything you guys did but found this post and that worked for me.
Turned of Gateway monitoring only and Dynamic DNS became online at once after a force refresh.
https://www.reddit.com/r/PFSENSE/comments/1kngpej/ddns_using_cloudflare_stopped_working_after/
-
@TheBigS try to check the option. For me worked
-
Yup the change of behaviour here is that the client checks the WAN is up by the gateway status on it before it tries to update. So if your gateway monitoring shows as offline the best solution here is to correct that so it's pinging something that responds. An alternative is to just mark the gateway as always up so it doesn't get monitored but then you lose gateway data.
-
@stephenw10 thanks a lot. my pfsense is now pinging quad9 and now everything is working.
-
...its the same here with pppoe and dhcp
using afraid, and hurricane electrics as ddns service.
but it's half bad, another reason why to abandon pfsense after nearly 18 years of usage.....
-
why in earth should I disable gateway monitoring since i have three pppoe connections and a dhcp connection which is a redundant setup for internet connection?!?
disabling gw monitoring is a very crude workaround for a problem which should not exist in the first place! Come on.... ddns is not rocket science!!!!
-
It seems as if it is the old problem from a couple of years ago coming back again:
whent you get an IPv6 Address via pppoe or dhcp you also get some link local addresses for that. somtimes even the default gw is link local.
It seems in some circumstances the ddns client of pfsense does not get the right ip address and makes a lot of silly stuff with the ll address....
because even if forcing the update and even when the given ipv6 address is the same as before it fails to "update" the ddns service and shows a cached "::" entry ....
I cannot say if the entry itself is getting updated, since, in my case, there is no change.....
BTW: I just encountered my 4 IPv6 WAN Adresses are totally mixed up in the ddns entries..... I don't recon any rule about how pfsense mangled it.... wan1 has ddns IP from wan3 wan 2 and 4 does not have any dyndns address. The addresses itself are correctly assigned to the correct interfaces in the interface section.
-
Ok so the issue you're seeing is only affecting IPv6 addresses?
And gateway monitoring is working fine for those IPv6 interfaces?
That seems separate to the issue other users here were hitting.
-
The IPv6 Addresses are not updated in the DNS. I checked that.
Why should that be another Issue? Gateway monitoring for itself is working fine as far as I can tell right now.
The ddns script does not resolve the current IPv6 Address - totaly irrelevant if I use a script or not - in the status display it is always "::" and not a current or past IPv6 Address.
-
Right, it's just that this seems to be a new/different issue to that which was discussed in this thread. Which was that a change in the behaviour of the dyndns update script meant it would not run against a WAN where the gateway is marked down.
As I understand it that's not what youre seeing?
