Hello, I have an IPfire that sits behind a Fortigate 60F that im using striclty for dual Wan failover for the IPfire red interface. It does not do any load balancing as again it is strictly for failover only if the primary WAN goes down. The Issue I am having is that the IPfire’s built in DDNS Update client does not update my Dyndns.org name even though it is set to check using the help of an external server but if I use the official DYNDNS Updater client from Dyndns on a PC sitting behind the IPfire, thier updater does update my wan IP address upon it changing.
If I run a force update from the IPfires CLI, it states that it updated it, but if I go check the DYNDNS site, it actually does not and it also still shows red under the Dynamic DNS tab in ipfires GUI.
Any help would be appreciated in solving this issue.
I looked at the log for IPS and nothing. Even Dynamic DNS logs show nothing unless I try to force update and again, it says it succeeded but it actually does not and in the dynamic GUI it stills shows red.
Only after the actual official DYNDNS updater client from dyndns checks and updates the WAN ip does it then turn green on the IPfire GUI.
I even disabled the IPS temporarily just to see if it would make any difference and nothing.
But again, I have Dyndns’s actual updater client installed on a computer and it will detect the wan IP has changed and it does update the actual wan IP on the dyndns site
Looking at the dyndns.org website I have not been able to find any information on the settings that have to be sent to compare them against what has been created in IPFire. Maybe dyndns.org have changed how they work.
The dyndns updater is no use in IPFire anyway as it requires libffi-3.2.1 (from 2014) and IPFire is currently running with libffi-3.5.2 and in CU205 it will be at libffi-3.7.1
For Ubuntu 18.04 and newer their workaround for their ddns updater package is to install the 2014 version of libffi.
Unfortunately trying to do any testing is not easy as they don’t provide any free DDNS services, only paid ones.
The closest I could find was a 7 day free trial on a $55/yr purchase.
I may have found what the issue is, although not certain.
In the providers.py code dyndns.org update is done in line with the abstract class DYNDNS2 which is the format used by a lot but not all DDNS providers.
This class format sends to the update url the hostname, IP, username and password.
Trying the url it comes up first with a box asking for the username and the password. Presumably, after providing those it then asks for the hostname and IP. That looks different compared to what the existing dyndns.org code is providing.
It looks to me like dyndns.org changed how they accept the info and no longer accept as a single input but require it to be done in two phases, logging in first to the update url and then providing the hostname and IP.
However no easy way to test this and I am not sure my coding skills are good enough to easily do that update to the ddns code in IPFire.