No-IP.org address not updating but DynDns.org updates fine - bug or ID10T error?



  • Hi everyone,

    I'm using both dyndns.org and no-ip.org and have pfSense set to keep both up to date.  DynDns.org is updating just fine but no-ip.org is not.  Every so often I still get the "your account is about to expire" warning from no-ip.  Both addresses show in green in the pfSense web interface.

    I've tried putting the credentials in several times (email address as username for no-ip) and doing a save, and according to the log it started the update the first time but did not refresh the IP since it's the same.  The IP for dyndns.org appears to have been refreshed even though it was the same, according to the log.  The update time on the no-ip website has not changed but dyndns.org shows the updated time.

    Here's a log excerpt, you can see where it successfully updated dyndns.org on 9/6 at 0101 as well as my attempt to get it to refresh/update the no-ip.org address today:
    Sep 6 14:05:01 php: /services_dyndns_edit.php: phpDynDNS: No change in my IP address and/or 25 days has not passed. Not updating dynamic DNS entry.
    Sep 6 14:05:01 php: /services_dyndns_edit.php: DynDns: Current WAN IP: 71.179.xx.xx Cached IP: 71.179.xx.xx
    Sep 6 14:05:01 php: /services_dyndns_edit.php: DynDns debug information: 71.179.xx.xx extracted from checkip.dyndns.org
    Sep 6 14:05:01 check_reload_status: Syncing firewall
    Sep 6 14:05:01 php: /services_dyndns_edit.php: DynDns: updatedns() starting
    Sep 6 14:02:32 php: /services_dyndns_edit.php: phpDynDNS: (Success) IP address is current, no update performed.
    Sep 6 14:02:32 php: /services_dyndns_edit.php: phpDynDNS: updating cache file /conf/dyndns_wannoip'mydomain.no-ip.org'.cache: 71.179.xx.xx
    Sep 6 14:02:32 php: /services_dyndns_edit.php: DynDns debug information: 71.179.xx.xx extracted from checkip.dyndns.org
    Sep 6 14:02:32 php: /services_dyndns_edit.php: DynDns: Current Service: noip
    Sep 6 14:02:32 php: /services_dyndns_edit.php: DynDns: DynDns _checkStatus() starting.
    Sep 6 14:02:32 php: /services_dyndns_edit.php: DynDns: DynDns _update() starting.
    Sep 6 14:02:32 php: /services_dyndns_edit.php: DynDns debug information: DynDns: More than 25 days. Updating. 1346954552 - 1343143344 > 2160000
    Sep 6 14:02:32 php: /services_dyndns_edit.php: DynDns: Current WAN IP: 71.179.xx.xx Cached IP: 71.179.xx.xx
    Sep 6 14:02:32 php: /services_dyndns_edit.php: DynDns debug information: 71.179.xx.xx extracted from checkip.dyndns.org
    Sep 6 14:02:32 check_reload_status: Syncing firewall
    Sep 6 14:02:32 php: /services_dyndns_edit.php: DynDns: updatedns() starting
    Sep 6 13:40:15 php: /index.php: Successful webConfigurator login for user 'admin' from 192.168.2.100
    Sep 6 13:40:15 php: /index.php: Successful webConfigurator login for user 'admin' from 192.168.2.100
    Sep 6 12:30:54 php: : /etc/rc.update_urltables: pfBlockerZeus does not need updated.
    Sep 6 12:30:54 php: : /etc/rc.update_urltables: pfBlockerDShield does not need updated.
    Sep 6 12:30:54 php: : /etc/rc.update_urltables: pfBlockerSpamhausDROP does not need updated.
    Sep 6 12:30:54 php: : /etc/rc.update_urltables: Starting URL table alias updates
    Sep 6 12:30:00 php: : /etc/rc.update_urltables: Sleeping for 54 seconds.
    Sep 6 12:30:00 php: : /etc/rc.update_urltables: Starting up.
    Sep 6 12:00:04 php: : [pfblocker] pfblocker_xmlrpc_sync.php is starting.
    Sep 6 12:00:04 check_reload_status: Reloading filter
    Sep 6 12:00:04 check_reload_status: Syncing firewall
    Sep 6 08:00:02 php: : [pfblocker] pfblocker_xmlrpc_sync.php is starting.
    Sep 6 08:00:02 check_reload_status: Reloading filter
    Sep 6 08:00:02 check_reload_status: Syncing firewall
    Sep 6 06:05:55 dhclient[52442]: bound to 192.168.1.5 – renewal in 43200 seconds.
    Sep 6 06:05:55 dhclient: Creating resolv.conf
    Sep 6 06:05:55 dhclient: RENEW
    Sep 6 06:05:55 dhclient[52442]: DHCPACK from 192.168.1.1
    Sep 6 06:05:55 dhclient[52442]: DHCPREQUEST on xl0 to 192.168.1.1 port 67
    Sep 6 04:00:03 php: : [pfblocker] pfblocker_xmlrpc_sync.php is starting.
    Sep 6 04:00:03 check_reload_status: Reloading filter
    Sep 6 04:00:03 check_reload_status: Syncing firewall
    Sep 6 01:01:02 php: : phpDynDNS: (Success) IP Address Changed Successfully! (71.179.xx.xx)
    Sep 6 01:01:02 php: : phpDynDNS: updating cache file /conf/dyndns_wandyndns'mydomain.dyndns.org'.cache: 71.179.xx.xx
    Sep 6 01:01:02 php: : DynDns debug information: 71.179.xx.xx extracted from checkip.dyndns.org
    Sep 6 01:01:01 php: : DynDns: Current Service: dyndns
    Sep 6 01:01:01 php: : DynDns: DynDns _checkStatus() starting.
    Sep 6 01:01:01 php: : DynDns: DynDns _update() starting.
    Sep 6 01:01:01 php: : DynDns debug information: DynDns: More than 25 days. Updating. 1346907661 - 1344661261 > 2160000
    Sep 6 01:01:01 php: : DynDns: Current WAN IP: 71.179.xx.xx Cached IP: 71.179.xx.xx
    Sep 6 01:01:01 php: : DynDns debug information: 71.179.xx.xx extracted from checkip.dyndns.org
    Sep 6 01:01:01 php: : DynDns: updatedns() starting

    Any ideas on what's going on here?  The email address associated with the account is what you use to login to the no-ip website, that IS what I should be using within pfSense, correct?

    EDIT:  I'm running the latest version:
    2.0.1-RELEASE (amd64)
    built on Mon Dec 12 18:16:13 EST 2011
    FreeBSD 8.1-RELEASE-p6

    Many thanks,

    • Phil


  • Update:
    The deafening silence here tells me that I'm not the only one who's confused by this behavior, so I wanted to follow up with some additional info I've gathered related to this problem.  As a result of what I've found, I've basically stopped using No-IP in favor of FreeDNS with DynDNS as a backup.  I really like the way FreeDNS will work with any domain you own in addition to providing their own domains for you to use like the other DNS services do.

    When I use No-IP's own DUC, it claims to successfully update according to the client log but the last update date still does not change on their website, so it would appear that No-IP doesn't advance the date if the IP doesn't change, requiring you to manually log in from time to time in order to keep the account from going inactive.  I'm sure it's an extra inconvenience that's intended to get you to sign up for paid services.  Hey, everyone's got to make money.

    I was thinking that pfSense was handling the two update services differently but it appears that No-IP is most likely responsible for this behavior.  There should probably be a sticky or perhaps even something in the pfSense UI that warns about this so others with long leases don't fall into the same trap, wondering why they can't keep their No-IP accounts active with pfSense.

    • Phil


  • I found similar behaviour. After some digging I found that you have to create a username with no-ip in your account. Using this account, the automatic updates from pfsense with no-ip work fine.

    Test:
    Changed the ip address in the webinterface of no-ip to a bogus value
    Force an update from the pfsense gui
    Refresh the webinterface of no-ip to see the proper IP address for the host again


  • LAYER 8 Global Moderator

    "I found that you have to create a username with no-ip in your account"

    What does that mean exactly.. I have a no-ip account that I use to update, but as stated if your IP doesn't change it doesn't seem to work.  You changed your IP on the website, so yeah when you updated from pfsense it would be a change and IP and work.



  • I'm assuming that you are referring to creating a sub-account, which is only available to Plus and Enhanced users for a fee.

    So if I understood you correctly and that's the case, then there still appears to be no way to do this with a free no-ip account.  It looks like pfSense, as well as no-ip's own update client is "logging in" just fine but if the IP hasn't changed, then no-ip won't update the "last update" date.

    • Phil


  • For info, this issue has been fixed on 2.1-BETA1 and later. See forum thread: http://forum.pfsense.org/index.php/topic,59231.0


Log in to reply