DynDNS

aeroliteflyer

Hello,
I am running pfSense 2.3 and just updated to build Fri Feb 19 13:06:52 CST 2016. After updating to this snapshot, my DynDNS is no longer updating. It has a red IP and the cached IP is no longer correct. I am using DynDNS custom configuration. I am using my username, not email or a @ in the username field. I did not copy and paste credentials and I know the credentials are correct. The logs show the cached IP != WAN IP and it runs updatedns(). Then the log has PAYLOAD: badauth and the final entry is (unknown response). Again, I am positive of credentials and hostname. Any thoughts?

BTW, I think the new interface is great.
Thanks,
Chris

cmb

What version were you on before the upgrade? Custom to what service? badauth should strictly be shown when auth failure is returned from the provider. Not seeing any recent changes that would impact auth, and dynamic DNS works in general.

phil.davis

Like @cmb says - there don't seem to be any changes that would effect the functional logic. I made a load of changes recently to the internationalization and formatting of the status messages in dyndns.class - https://github.com/pfsense/pfsense/commit/9557ca304bf09b5ff4c198e69502ca6657e5e82a - but I checked through that and it is all gettext() and code to just construct the messages, nothing that changes the flow of the logic.

So we will need the answers to @cmb questions above so we can narrow down what is happening.

cmb

Yeah the gettext changes probably looked the most suspect out of anything, but at a look through those I don't see where that could cause any changes with the credentials passed to the service, those weren't impacted. The changes I made recently all work too, and if they didn't, they'd cause the IP to be updated to go missing, and that'd fail well before it got to badauth.

aeroliteflyer

Thanks for the replies everyone. The custom is the service type in the Dynamic DNS settings. There is a drop down for service and there are three settings for DynDNS: custom, static and dynamic. I have it on custom. I am 100% positive of the credentials. I can update on the Windows client with no problem. I don't remember the update previous, but I update pfSense everyday with the autoupdate in the dashboard so I am pretty sure I am getting at least most if not all snapshots. I don't know if it was the latest pfSense snapshot that is a problem, as at that same reboot my IP also changed from the ISP triggering a DNS update. I know the dynamic DNS doesn't update if there's no change in IP. I pasted below the system logs copied from the GUI (IP and hostname omitted).

Feb 19 21:21:39 php-fpm 39307 /services_dyndns_edit.php: phpDynDNS (xxxxxx.dyndns.org): (Unknown Response)
Feb 19 21:21:39 php-fpm 39307 /services_dyndns_edit.php: phpDynDNS (xxxxxx.dyndns.org): PAYLOAD: badauth
Feb 19 21:21:39 php-fpm 39307 /services_dyndns_edit.php: Dynamic DNS dyndns-custom (xxxxxx.dyndns.org): _checkStatus() starting.
Feb 19 21:21:38 php-fpm 39307 /services_dyndns_edit.php: Dynamic DNS dyndns-custom (xxxxxx.dyndns.org): _update() starting.
Feb 19 21:21:38 php-fpm 39307 /services_dyndns_edit.php: Dynamic DNS (xxxxxx.dyndns.org): running get_failover_interface for wan. found hn1
Feb 19 21:21:38 php-fpm 39307 /services_dyndns_edit.php: Dynamic DNS dyndns-custom (xxxxxxx.dyndns.org): x.x.x.x extracted from local system.
Feb 19 21:21:38 php-fpm 39307 /services_dyndns_edit.php: Dynamic DNS: updatedns() starting

aeroliteflyer

I want to add one more thing. In my DynDNS account, I don't see any log of pfSense updating the IP. I do see the last log an update was made, by the Windows client. So it doesn't seem to be just a feedback issue.

cmb

I don't recall exactly what dyn's logs will show you, but they're most certainly sending you "badauth" as the reply. They probably don't add to the update log upon auth failure.

Only thing I can think of, have you put your password in again, while making sure you don't have any form fillers/password managers enabled? Lastpass bit me there once recently, overwriting the password.

aeroliteflyer

Yeah, I put the password in by hand numerous times. I even went to the xml file in pfSense that actually stores the login credentials and checked that, and it's correct. I am baffled, the Windows client works fine. Could be a cert issue? I remember reading something about DynDNS is using TLS?

Thanks,
Chris

cmb

If there were a cert problem it would fail well before that, and wouldn't have the provider response code as it wouldn't send a request to obtain a reply.

If you enable verbose logging do you get anything more in the logs?

MikeV7896

I always thought that "DynDNS (custom)" would be used if you had your own domain name using Dyn services… but if you were using their domain(s), you should be using "DynDNS (dynamic)" instead? Am I wrong about that? What's the difference between the three different DynDNS options?

aeroliteflyer

I changed from custom to dynamic in the DynDNS settings. Now the instead of the cached IP being the previous IP, in red, it is now quad zero in red. I do have verbose logging on. The log entries are the same as before.

Chris

cmb

@aeroliteflyer:

I changed from custom to dynamic in the DynDNS settings. Now the instead of the cached IP being the previous IP, in red, it is now quad zero in red.

That's what I'd expect after switching service types, that removes the cached IP so you end up with 0.0.0.0 until it updates successfully for the first time.

@virgiliomi:

I always thought that "DynDNS (custom)" would be used if you had your own domain name using Dyn services… but if you were using their domain(s), you should be using "DynDNS (dynamic)" instead? Am I wrong about that? What's the difference between the three different DynDNS options?

I was wondering the same thing. That dates way back, to when they were named DynDNS and not Dyn. If the diff service types had differing config options or update URLs or error response codes, that'd be why you might have 3 diff types. But looking at /etc/inc/dyndns.class, those 3 all do exactly the same thing. Haven't looked back in the history to see if things used to be different way back at some point. That probably should be consolidated to one, and renamed to Dyn, at some point.

I think we almost certainly would have heard from another Dyn user if it were completely non-functional. But they're not nearly as widely used since discontinuing free accounts, so maybe not.

My best suggestion at this point is to go back to the point where it worked (which in this case is easy, just replacing one file), and see if it still works. Replace /etc/inc/dyndns.class with:
https://raw.githubusercontent.com/pfsense/pfsense/e8f35ce462e8af23cb7d1af8ca59bee856a6e7bc/src/etc/inc/dyndns.class
and you'll be back to how it was from February 4-14, which I believe is where your last working snapshot fell. Then trigger a dyndns update, and see what happens.

r-daneel

Hi,

I just installed pfSense to replace a small wifi router that was working fine with DynDNS.
Found this topic because I got the exact same error message (even changing the type did not help).

I'll try the code change to see if that solves the issue.

Will let you know shortly.

r-daneel

So, I replaced the code in dyndns.class with :
https://raw.githubusercontent.com/pfsense/pfsense/e8f35ce462e8af23cb7d1af8ca59bee856a6e7bc/src/etc/inc/dyndns.class

Now logs are different. Worse in a sense ;)


php-fpm[67544]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn) There was an error trying to determine the public IP for interface - (). Probably interface is not a WAN interface.
php-fpm[67544]: /services_dyndns_edit.php: phpDynDNS: (ERROR!) No Password Provided.

So I guess the code has changed too much.

Meanwhile, here are the logs I get with the original code:

php-fpm[70638]: /services_dyndns_edit.php: phpDynDNS (my.hostname.fqdn): (Unknown Response)
php-fpm[70638]: /services_dyndns_edit.php: phpDynDNS (my.hostname.fqdn): PAYLOAD: badauth
php-fpm[70638]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn): Current Service: dyndns-custom
php-fpm[70638]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn): DynDns _checkStatus() starting.
php-fpm[70638]: /services_dyndns_edit.php: DynDNS: (my.hostname.fqdn) DNS update() starting.
php-fpm[70638]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn): DynDns _update() starting.
php-fpm[70638]: /services_dyndns_edit.php: DynDNS (my.hostname.fqdn): running get_failover_interface for wan. found rl0
php-fpm[70638]: /services_dyndns_edit.php: DynDns (my.hostname.fqdn): XXX.XXX.XXX.XXX extracted from local system.
php-fpm[70638]: /services_dyndns_edit.php: DynDns: updatedns() starting

Credentials have been checked.

Any clue ?

P.S.: also tried ZoneEdit and it worked flawlessly.

r-daneel

Hi,

Good news.

I was fiddeling with the update URL for DynDNS trying to understand what was failing.
I used curl to do so (https://help.dyn.com/remote-access-api/perform-update/).
Also tried FireFox at some point.
Indeed, 'badauth' indicates authentication failure (https://help.dyn.com/remote-access-api/return-codes/).

I tried to update a standard 'host.dyndns.org' entry but still failed to authenticate.

While searching I found an old post (https://wiki.openwrt.org/doc/howto/ddns.client) stating:

'badauth' in Update Output, you have to change your password which contains only letters and numbers. Because busybox's (v1.15.3) wget implementation has an issue handling encoded URLs

As it did not work at first (during my very first attempts in pfSense), I switched back to the regular password for my account (just in case), full of special characters.
After reading the above post, I reverted to using the 'Updater Client Key' you can get on the 'Account Settings' page.

Now this worked for the dyndns.org domain. Also using it to update my FQDN worked.

I can't tell why I had failures using the 'Updater Client Key' in the first place, but well … now it works.

Hope this helps out.

cmb

@r-daneel:

So, I replaced the code in dyndns.class with :
https://raw.githubusercontent.com/pfsense/pfsense/e8f35ce462e8af23cb7d1af8ca59bee856a6e7bc/src/etc/inc/dyndns.class

Now logs are different. Worse in a sense ;)

Guessing you must be on 2.2.x, since the called parameters are different there, in which case that file won't work.

Could you narrow down which character in particular is causing an issue?

hasenfrasen

@cmb:

Could you narrow down which character in particular is causing an issue?

I have also noticed it had stopped working with dyndns. I change the password (example) from "n1ssehult" to "N1ssehult!" and it works again. Dunno why, but it works!

cmb

@hasenfrasen:

I have also noticed it had stopped working with dyndns. I change the password (example) from "n1ssehult" to "N1ssehult!" and it works again. Dunno why, but it works!

In that case you actually added a special character? That sounds like the password change on Dyn's side made it start working rather than anything to do with the contents of the password.

hasenfrasen

@cmb:

In that case you actually added a special character? That sounds like the password change on Dyn's side made it start working rather than anything to do with the contents of the password.

I also have a Asus RT-N65U (padavan fw) using the same DYN-Pro account (different hostname though) for two years that has worked fine lately while pfsense didn't. I also have three other (total four) virtual pfSense installations using four different hostnames, all fails the same. Either the uppercase or the exclamation did it. Dunno.

I know the DYN password was correct as I was able to log in to their site using the "wrong" password, but the "correct" credentials in pfSense failed. I have deleted and recreated the DDNS client entry numerous times in pfSense and thought… alzheimer? Phew... anyhow, it works with "special/upper" characters added.