Cloudflare Dynamic DNS error

Alex Atkin UK

I've tried the global key and API key configuration, both fail with no good explanation in the logs.

Aug 14 01:29:26 Router php-fpm[72095]: /services_dyndns_edit.php: phpDynDNS (three): UNKNOWN ERROR -
Aug 14 01:29:26 Router php-fpm[72095]: /services_dyndns_edit.php: phpDynDNS (three): PAYLOAD:
Aug 14 01:29:26 Router php-fpm[72095]: /services_dyndns_edit.php: Dynamic DNS cloudflare (three.##.co.uk): _checkStatus() starting.
Aug 14 01:29:26 Router php-fpm[72095]: /services_dyndns_edit.php: Response Data:
Aug 14 01:29:26 Router php-fpm[72095]: /services_dyndns_edit.php: Response Header:
Aug 14 01:29:26 Router php-fpm[72095]: /services_dyndns_edit.php: Dynamic DNS cloudflare (three.##.co.uk): _update() starting.
Aug 14 01:29:26 Router php-fpm[72095]: /services_dyndns_edit.php: Dynamic DNS (three.##.co.uk): running get_failover_interface for opt15. found gif0
Aug 14 01:29:26 Router php-fpm[72095]: /services_dyndns_edit.php: Dynamic DNS cloudflare (three.##.co.uk): ##.40.##.225 extracted from local system.

stephenw10

Did you enable verbose logging? It looks like you did.

What pfSense version is that in?

You used the appropriate username for both those options?

Steve

Alex Atkin UK

@stephenw10 said in Cloudflare Dynamic DNS error:

Did you enable verbose logging? It looks like you did.

What pfSense version is that in?

You used the appropriate username for both those options?

Steve

I can't remember what constitutes verbose logging but I will have a guess it probably got enabled in the past, as I also send the logs over syslog to my NAS so I can look at them deeper there.

I've tried changing the credentials for DDNS several times between the two options, re-reading the documentation, looking up guides. My Cloudflare API key is already used for letsencrypt on my NAS so I know that works.

I'm on pfSense 2.5.2-RELEASE.

stephenw10

Verbose logging is an option in the DynDNS service setup. The logs you have look like it's probably enabled already but if not you should enable it.

Steve

Alex Atkin UK

@stephenw10 said in Cloudflare Dynamic DNS error:

Verbose logging is an option in the DynDNS service setup. The logs you have look like it's probably enabled already but if not you should enable it.

Steve

Oh right, yes that's definitely on.

stephenw10

Hmm, not seeing any open bugs for the Cloudflare client. It clearly was working at one time.

What config are you setting there exactly?

Steve

johnpoz

I just tried to duplicate this problem - and working fine here..

I am running 21.05.1

Did a public query for it, and resolving just fine

Here are my settings.

stephenw10

Nice.

johnpoz

I was able to get it to fail, if the A record didn't already exist in cloudflare. I edited the ddns setting pfsense to testhome..

This failed.. Until I created the A record in cloudflare with that fqdn -- I just put in IP 1.2.3.4, then forced update and it changed it to my public IP 64.x.x.x

Alex Atkin UK

I figured out the problem and it seems to be a bug in the UI.

The key was "running get_failover_interface for opt15. found gif0" which bothered me from the start. Why would it need a failover? If the WAN is down there would be no IP to update it with! Why would it be looking at my IPv6 tunnel?

Then by fluke I noticed an extra field flash up when loading the page called "Interface to send update from" which the first entry in there was, you guessed it, HENET (gif0).

So I went into inspect element and removed the hidden class from that menu option, changed it to the correct WAN interface, clicked Save & Apply and bam - it worked.

stephenw10

Hmm, so you have it set to monitor gif0 but it cannot send updates from there?

Alex Atkin UK

@stephenw10 said in Cloudflare Dynamic DNS error:

Hmm, so you have it set to monitor gif0 but it cannot send updates from there?

No, its monitoring opt19 but for some reason was trying to send updates out of opt15 (gif0).

So I had to enable that hidden form field to manually change it.

Question is, why is that form field even there and why is it hidden? I can only assume Firefox submitted the field even though its hidden (this is expected behaviour) and so the wrong interface got assigned, as gif0 was at the top of the list.

I also noticed if I tried to monitor a ppp interface the IP just said n/a and it didn't even give a tick or cross. Fortunately I don't need to do that as both are static IPs, I just tried it while testing.