"
Hello @all,
it seems that the DynDNS plugin (both legacy and ddclient) doesn't quite do what I expect it to do, namely:
- Determine the current public IPv4 (WAN IP) with which the LAN is connected to the Internet (default route)
- Determine the IP to which the DynDNS domain currently resolves (DynDNS IP).
- Check whether WAN IP and DynDNS IP are identical
- If not: Set the DynDNS IP to the WAN IP
What does the DynDNS plugin actually do?
- Do we have a new WAN IP? Then set the DynDNS IP to the new WAN IP
What doesn't the DynDNS plug-in do?
- Compare the actual WAN IP with the one set by DynDNS IP and correct the latter if necessary
What is the problem with this?
Well, in a standard scenario, this behaviour may not be a problem at first: The DynDNS IP is set the first time the plugin is called as well as every time the IP changes, which is used publicly on the WAN side. In the interval defined under 'General settings', only the service selected in 'Check ip method' is queried and it is checked whether the IP determined there has changed since the last query. If this is not the case, the process is ended for this interval. The last valid WAN IP is cached for this. So far, so good.
However, there are situations (both intentional and unintentional) in which this mechanism fails:
- There are cases in which the IP of the Dyn domain is changed by external events and is therefore no longer identical to the current WAN IP. The DynDNS plug-in will not notice this and will not take any measures to rectify this situation - i.e. to set the DynDNS IP back to the value of the WAN IP. This means that remote users (or worse: remote admins) are cut off from the system.
- Similar problems have been reported with multi-WAN systems (e.g. here: "Dynamic DNS issues with ddclient" ¹ ): If WAN-A fails and WAN-B takes over as the default route, the DynDNS IP is set to the (variable) IP of WAN-B. If WAN-A comes back online and resumes the default route with the same (fixed) IP as before the failure, the DynDNS plug-in sees no need to set the DynDNS IP back to the IP of WAN-A, as this has not changed on the WAN-A connection.
In our view, the correct behaviour would be for the DynDNS plug-in to compare the actual WAN IP with the DynDNS IP at each new check interval and correct the latter if there is a discrepancy.
The fact that this effect occurs identically for both backends (legacy and ddclient) suggests that this behaviour is to be found in the logic of OPNsense itself. The difference can only be seen in the type of log entries:
- ddclient: "SUCCESS: <my.dyndns.tld>: skipped: IP address was already set to 12.34.56.67″ (Note: the DynDNS domain actually points to e.g. 44.55.66.77!)
- legacy: "Account cd4ae814–9d20–4fc4-a25b-7e1fb1afccc6 [<service> - <description>] not modified"
Do we have to write a cron script ourselves to correct this behaviour or is there a more elegant way?
(Last tested under OPNsense 24.1.10_8-amd64, os-ddclient1.22)
¹) https://forum.opnsense.org/index.php?topic=32453.0
it seems that the DynDNS plugin (both legacy and ddclient) doesn't quite do what I expect it to do, namely:
- Determine the current public IPv4 (WAN IP) with which the LAN is connected to the Internet (default route)
- Determine the IP to which the DynDNS domain currently resolves (DynDNS IP).
- Check whether WAN IP and DynDNS IP are identical
- If not: Set the DynDNS IP to the WAN IP
What does the DynDNS plugin actually do?
- Do we have a new WAN IP? Then set the DynDNS IP to the new WAN IP
What doesn't the DynDNS plug-in do?
- Compare the actual WAN IP with the one set by DynDNS IP and correct the latter if necessary
What is the problem with this?
Well, in a standard scenario, this behaviour may not be a problem at first: The DynDNS IP is set the first time the plugin is called as well as every time the IP changes, which is used publicly on the WAN side. In the interval defined under 'General settings', only the service selected in 'Check ip method' is queried and it is checked whether the IP determined there has changed since the last query. If this is not the case, the process is ended for this interval. The last valid WAN IP is cached for this. So far, so good.
However, there are situations (both intentional and unintentional) in which this mechanism fails:
- There are cases in which the IP of the Dyn domain is changed by external events and is therefore no longer identical to the current WAN IP. The DynDNS plug-in will not notice this and will not take any measures to rectify this situation - i.e. to set the DynDNS IP back to the value of the WAN IP. This means that remote users (or worse: remote admins) are cut off from the system.
- Similar problems have been reported with multi-WAN systems (e.g. here: "Dynamic DNS issues with ddclient" ¹ ): If WAN-A fails and WAN-B takes over as the default route, the DynDNS IP is set to the (variable) IP of WAN-B. If WAN-A comes back online and resumes the default route with the same (fixed) IP as before the failure, the DynDNS plug-in sees no need to set the DynDNS IP back to the IP of WAN-A, as this has not changed on the WAN-A connection.
In our view, the correct behaviour would be for the DynDNS plug-in to compare the actual WAN IP with the DynDNS IP at each new check interval and correct the latter if there is a discrepancy.
The fact that this effect occurs identically for both backends (legacy and ddclient) suggests that this behaviour is to be found in the logic of OPNsense itself. The difference can only be seen in the type of log entries:
- ddclient: "SUCCESS: <my.dyndns.tld>: skipped: IP address was already set to 12.34.56.67″ (Note: the DynDNS domain actually points to e.g. 44.55.66.77!)
- legacy: "Account cd4ae814–9d20–4fc4-a25b-7e1fb1afccc6 [<service> - <description>] not modified"
Do we have to write a cron script ourselves to correct this behaviour or is there a more elegant way?
(Last tested under OPNsense 24.1.10_8-amd64, os-ddclient1.22)
¹) https://forum.opnsense.org/index.php?topic=32453.0
