Dynamic DNS client causes Cloudflare to grey-cloud domain
-
I host some services at home, and I use Cloudflare for DNS and to hide my IP address. I use the dynamic DNS client in pfSense to keep the IP up to date with the domain in Cloudflare.
However, when pfSense detects an IP address change and updates the domain in Cloudflare, it also grey-clouds* it. This means my home IP is exposed until I log into Cloudflare and manually orange-cloud the domain again. Obviously, this is not ideal.
I did look at the Cloudflare dynamic DNS API a while ago and I seem to remember it's a single part of the string which can set either orange-cloud, grey-cloud, or do not change. It seems that pfSense is hard coded to grey-cloud.
*grey cloud = Cloudflare provides DNS only, and origin server IP address is exposed
*orange cloud = Cloudflare provides DNS and proxying; all requests to the domain go through Cloudflare and origin server is not exposed -
I'm experiencing the exact same issue.
-
So, I looked into this problem while I was also figuring out how to get pfSense to update the A record on my CloudFlare zone. Finally found the forum posts on that, and suffice it to say, it's not well documented.
Anyhow, it turns out that the function to enable or disable the CloudFlare proxy on a record was added to the Dynamic DNS form via a revision made 8 months ago, but I believe it was not very well implemented, and the fact that the option to enable or disable the proxy doesn't show up was never caught. That said, I don't know for sure, and there may very well be reason for leaving it hidden.
That revision, BTW, is: https://redmine.pfsense.org/projects/pfsense/repository/revisions/e10d25b4c3109347a43a729f8c098138272fe1e7
The way the form works is that, based on the provider you choose, certain form elements are either enabled or disabled through the use of a case statement. For CloudFlare (cloudflare/cloudflare-v6 in the case statement) there appears to be multiple CloudFlare entries in the statement, and the final cloudflare case statement is missing a trailing break. As far as I can tell, the missing break statement causes the default options to be used instead, which leaves the proxy element disabled.
Fixing the statement by removing the extra entries and adding the missing break statement causes the checkbox element for the proxy feature to appear.
I've tested CloudFlare updates with the proxy enabled and disabled multiple times, and it all seems to be working now.
Here's a diff:
--- /usr/local/www/services_dyndns_edit.php.original 2017-05-23 17:29:14.827266000 -0700 +++ /usr/local/www/services_dyndns_edit.php 2017-05-24 09:59:14.533227000 -0700 @@ -504,8 +504,6 @@ hideInput('ttl', false); break; case "namecheap": - case "cloudflare-v6": - case "cloudflare": case "gratisdns": case "hover": hideGroupInput('domainname', false); @@ -523,7 +521,7 @@ break; case "cloudflare-v6": case "cloudflare": - hideGroupInput('domainname', true); + hideGroupInput('domainname', false); hideInput('resultmatch', true); hideInput('updateurl', true); hideInput('requestif', true); @@ -534,7 +532,8 @@ hideCheckbox('wildcard', false); hideCheckbox('proxied', false); hideInput('zoneid', true); - hideInput('ttl', false); + hideInput('ttl', true); + break; default: hideGroupInput('domainname', true); hideInput('resultmatch', true);Obviously you need to be comfortable SSHing into your appliance, and editing the PHP file via su or sudo. I need to figure out how I can contribute the fix upstream so it doesn't get lost on upgrade, but the information could help you out in the short term.
EDIT: Notice some other form elements were disabled with the corrected case statement, so I corrected the correction.
Also, I'm running version 2.3.4-release of pfSense. If you want to make the changes on your own, and you're not running that version, your on-appliance PHP file may differ.
-
Actually, it looks like there's already an open pull request to fix this problem.
https://github.com/pfsense/pfsense/pull/3717
-
Actually, it looks like there's already an open pull request to fix this problem.
https://github.com/pfsense/pfsense/pull/3717
Great, I see the pull request has been approved too, does that mean the fix will make it into the next update?
I rely quite heavily on this feature working properly, so it would be great if it is 8)
-
Great, I see the pull request has been approved too, does that mean the fix will make it into the next update?
I rely quite heavily on this feature working properly, so it would be great if it is 8)
That's a good question, but I imagine it'd probably be in the next point release or update.
Since it's the first time I've contributed to the development of pfSense in any fashion, I have no idea how long it'll take to see this get bubbled up.