Cloudflare DDNS: UNKNOWN ERROR

[logan893]

I'm attempting to use Dynamic DNS service to update the IP of a Cloudflare subdomain, using the Zone ID API key as username, and an API token with "Edit zone DNS" (from template) permission as password.

The verbose logging is switched on, but I get nothing useful from the system logs output. Not finding any similar problems when searching.

I believe this was working 4 months ago, but I haven't kept track of it since and I see now that it's broken.

I've tried changing the password to the Global API key, or a newly created "Edit zone DNS" token, but the same behavior persists in pfsense.

I'm running pfSense 2.5.2

Has there been any changes on the Cloudflare side that are now incompatible with the DDNS service pfSense 2.5.2?

How do I proceed with any troubleshooting when the verbose logging gives me such limited information?

Any help is appreciated.

Jun 14 09:53:57 pfsense php-fpm[64818]: /services_dyndns_edit.php: Dynamic DNS: updatedns() starting
Jun 14 09:53:57 pfsense php-fpm[64818]: /services_dyndns_edit.php: Dynamic DNS cloudflare (subdomain.example.com): xx.xx.xx.xx extracted from local system.
Jun 14 09:53:57 pfsense php-fpm[64818]: /services_dyndns_edit.php: Dynamic DNS (subdomain.example.com): running get_failover_interface for wan. found vtnet0
Jun 14 09:53:57 pfsense php-fpm[64818]: /services_dyndns_edit.php: Dynamic DNS cloudflare (subdomain.example.com): _update() starting.
Jun 14 09:53:57 pfsense php-fpm[64818]: /services_dyndns_edit.php: Response Header:
Jun 14 09:53:57 pfsense php-fpm[64818]: /services_dyndns_edit.php: Response Data:
Jun 14 09:53:57 pfsense php-fpm[64818]: /services_dyndns_edit.php: Dynamic DNS cloudflare (subdomain.example.com): _checkStatus() starting.
Jun 14 09:53:57 pfsense php-fpm[64818]: /services_dyndns_edit.php: phpDynDNS (subdomain): PAYLOAD:
Jun 14 09:53:57 pfsense php-fpm[64818]: /services_dyndns_edit.php: phpDynDNS (subdomain): UNKNOWN ERROR -

[logan893]

I had a look at the /etc/inc/dyndns.class file to see what it's supposed to do, and I replicated the API calls manually towards the api.cloudflare.com v4 service from a server on my LAN with internet access via the pfsense FW. Using the API commands that should be executed by the dyndns component, I am able to update the cloudflare DNS IP.

Doesn't make sense to me why pfSense is failing in this way.

[logan893]

I'm digging some more by adding debug logging to the code. The curl_exec command is failing (returning false). There's no error text from curl_error (returns empty string), but the curl_errno return value is 7, which according to the documentation means CURLE_COULDNT_CONNECT.

Manually executing 'curl -X GET "https://api.cloudflare.com/client/v4/..." -H headers' from the pfsense command line works and gives proper results in return.

The output from curl_info is almost identical before vs after execution, with the exception of a few of the time metrics being updated from 0.

After failure of curl_exec (errno 7), curl_getinfo contains: url=https://api.cloudflare.com/client/v4/zones/xxxxx/dns_records?name=subdomain.example.com&type=A, content_type=, http_code=0, header_size=0, request_size=0, filetime=-1, ssl_verify_result=0, redirect_count=0, total_time=0.002556, namelookup_time=0.00365, connect_time=0, pretransfer_time=0, size_upload=0, size_download=0, speed_download=0, speed_upload=0, download_content_length=-1, upload_content_length=-1, starttransfer_time=0, redirect_time=0, redirect_url=, primary_ip=, certinfo=Array(<empty>), primary_port=0, local_ip=, local_port=0, http_version=0, protocol=0, ssl_verifyresult=0, scheme=, appconnect_time_us=0, connect_time_us=0, namelookup_time_us=3650, pretransfer_time_us=0, redirect_time_us=0, starttransfer_time_us=0, total_time_us=2556,

[logan893]

I've tracked it down to the following:

The IP fetched for WAN is correct, and taken from the bridge0 interface (a bridge of vtnet0 and vtnet1). This interface has the WAN IP DHCP client configuration, while vtnet0 and vtnet1 have no IP configuration set.

While DDNS finds the correct IP, it also looks for an interface and picks vtnet0 (vtnet1 interface is currently down). Since vtnet0 has no IP configured, this makes curl_exec fail in this way.

If I override the interface selection via curl_setopt($ch, CURLOPT_INTERFACE, 'if!bridge0');, the Cloudflare DDNS configuration works.

Perhaps it's incorrect to use function get_failover_interface here, or the behavior is not correct for my scenario.

Edit: raised a bug report. https://redmine.pfsense.org/issues/15557

[Popolou]

Works fine on this end, exactly the same way but the configuration in 2.7.2 no longer asks for a username for Cloudflare. Instead, it is blank and the password is the API key.