Dynamic DNS client "extracted from local system"

Gertjan

@b3nw said in Dynamic DNS client "extracted from local system":

I'm a bit baffled by this behavior, but is there any way to disable it?

This :

@b3nw said in Dynamic DNS client "extracted from local system":

extract an IP from the local system instead of attempting to check IP service

By default, no updates happens.
Then, the actual WAN IP is is determined by using using Services > Dynamic DNS > Check IP Services :: http://checkip.dyndns.org (click on it ^^).
This IPv4 is compared with the IPv4 as it successfully was communicated to your DynDNS system you use.
Nice advantage here : no need to contact DynDNS to know what is stored over there.

Note : Uisng http://checkip.dyndns.org costs some resouces, but as you saw, the html page that came back only contains the IPv4, nothing more. This is a very small 'load'.

It is strickly 'forbidden' to update the IPv4 'no matter what, as this could mean that you could start to update the IP WAN 'every 5 minutes' or so. Ok, you think, but if everybody was doing this, the DynDNS service would get DOSSed, there services would go red hot, and they will stop offering a free DynDNS service. They will advise you to repair your script, or take their non-free DynDNS service.

So, the goal is : only update (or contact) the DynDNS if there was a real WAN IP change.

To know if the WAN IP really changed ? Easy. Store the latest succeeded updated WAN IPv4 address locally. This is the cache file. Compare the actual WAN IPv4 with the cache ;:

if ($cacheIP != $wan_ip) {

and update only if they are different.

This test compares the IPv4 in the local cache file with the current WAN IPv4 (tested with http://checkip.dyndns.org). If it doesnt' match, an update happens.

If you update 'no matter what' your update can be considered as abusive.
Do this several times, and they will break your contract : you loose your DynDNS.

Gertjan

@johnpoz said in Dynamic DNS client "extracted from local system":

why would you have dynamic dns setup on an interface with a ULA?

Now I'm getting confused.
The IP - a IPv6 - is 'checked'.

First check : if $this->_useIPv6 == true (it is) the IPv6 of the (a) interface WAN interface is collected.
If it has not a valid IPv6 (fc00:bbbb:bbbb:bb01::5:1d9a is a valid IPv) then return 'fail'.

So the checks continue.
But wait ....
There are no checks anymore, just the line

log_error(sprintf(gettext('Dynamic DNS %1$s (%2$s): %3$s extracted from local system.'), $this->_dnsService, $this->_FQDN, $ip_address));

which is the subject line of this thread ^^

There is no validity check on IPv6 ( !! )
Like : "don't use a non routable Ipv6 "
fc00:bbbb:bbbb:bb01::5:1d9a is somewhat comparable to RFC1819 : it non routable so useless here.

Strange also the the dyndns services used"porkbun-v6" accepts this IPv6.
( or maybe I don't understand IPv6 not entirly - my guts tells me that fc00:bbbb:bbbb:bb01::5:1d9a can't be sued here and should be refused as a WAN IPv6 )

johnpoz

@Gertjan said in Dynamic DNS client "extracted from local system":

Strange also the the dyndns services used"porkbun-v6" accepts this IPv6.

Yeah that would be like putting rfc1918 in public dns. And really should be considered a rebind as well.

He mentions something about a vpn as well - but at a loss why you would want to use some ddns on an interface with ULA address to be honest.

Nor do a see the point in running a ULA on an interface that also has a GUA.. So maybe if @b3nw explains his setup and what exactly he is trying to register in ddns and why we might be able to get to the bottom of what is going on.

stephenw10

I suspect this was just never implemented because the vast majority of IPv6 cases would have a routable IP on the interface. It checks for IPv4 because being stuck behind NAT there is common.

Using a ULA subnet behind NAT is a corner case. Probably better to open a feature request if that's the case.

b3nw

So the use case is for Wireguard VPN's (and probably others) -- if they have IPv6 connectivity, they assign you one of these fc00 addresses, and then route you out the exit for the VPN, rather than giving you an actual routable IPv6.

So my expectation was that DynDNS would attempt to connect via the interface, and if it failed, then potentially fall back to something like "extracted from the local system". But it seems never to actually attempt to make the connection to the DynDNS provider.

Should this be a bug?

stephenw10

Probably a feature request since, as I say, I suspect it was never implemented.

You could reference this: https://redmine.pfsense.org/issues/13901

Oh looks like there is a request open already: https://redmine.pfsense.org/issues/11177

And @marcosm has already implemented it! Just waiting to be tested/merged. That's not going to make 24.11 at this point though. Let's see....

Edit: Some more work required there it doesn't apply directly right now.

johnpoz

@b3nw so in this case the exit is expected to nat the ULA to some GUA on the exit? So wireguard does this, or is pfsense expected to do it?

stephenw10

Doesn't really matter where it's done. Just the idea of having to NAT IPv6 is...... urgh. But if that's what you have then you'd want DDNS to be able to find the external IP.

johnpoz

@stephenw10 true - but if it something that has to be setup specific in pfsense to account for this sort of unique setup..

stephenw10

Yup it's a pretty edge case, hence not much complaining yet!

You would only ever want to do this on pfSense if the IPv6 address is unavailable there so the NAT must be happening at some remote location out of the control of the user.

b3nw

This seems to be the solution that is being implemented by VPN providers who support wireguard, but don't want to issue addressable IPv6 to end clients. NAT is handled by the VPN provider transparently.

b3nw

@stephenw10 https://redmine.pfsense.org/issues/11177 links to a non-resolvable gitlab PR, is there another one?

stephenw10

Not yet. But I tested that here and it doesn't apply cleanly to anything right now.

Once 24.11 is released there will be more dev time to look at it again.

SteveITS

@Gertjan said in Dynamic DNS client "extracted from local system":

To know if the WAN IP really changed ? Easy. Store the latest succeeded updated WAN IPv4 address locally. This is the cache file. Compare the actual WAN IPv4 with the cache ;:

Just going to take this opportunity to point out that this causes a problem in the case where we restore to a replacement router in our lab before delivery. DDNS is updated to our office IP. Live router will not update because its cached IP didn’t change. (Workaround is to manually modify the file on disk to fool it, as I recall)