Dynamic DNS client "extracted from local system"

[b3nw]

It's super confusing why the Dynamic DNS client would ever extract an IP from the local system instead of attempting to check IP service, yet when I look in my logs...

Nov 13 03:33:50 pfsense php-fpm[16222]: /services_dyndns_edit.php: Dynamic DNS pb -v6 (hostname.io): fc00:bbbb:bbbb:bb01::5:1d9a extracted from local system.
Nov 13 03:33:50 pfsense php-fpm[16222]: /services_dyndns_edit.php: phpDynDNS: updating cache file /conf/dyndns_opt5pbn-v6'mv.io'11_v6.cache: fc00:bbbb:bbbb:bb01::5:1d9a
Nov 13 03:33:50 pfsense php-fpm[16222]: /services_dyndns_edit.php: phpDynDNS (mv.den): (Success) IP Address Updated Successfully!

some interfaces/hostnames adjusted in this log for privacy.

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

[stephenw10]

Try enabling verbose logging if it's not already.

How many IPv6 addresses does that interface have?

Does it actually have a routable v6 address?

Also I don't think the default check IP service has a v6 address . Try using: ifconfig.me

[b3nw]

This is using ifconfig.me, curl from the interface works just fine, the log seems to suggest it works just fine, yet it then reverts to extracting the IP from the interface, which is confusing. I modified the hostname here for privacy.

Only 1 IP on the interface, and other IPv6 interfaces (non VPN/fc00::) work just fine with this setup.

Nov 14 04:10:46 php-fpm 13000 /services_dyndns_edit.php: Dynamic DNS porkbun-v6 (mullvard.local): _update() ending.

Nov 14 04:10:46 php-fpm 13000 /services_dyndns_edit.php: Dynamic DNS porkbun-v6 (mullvard.local): _checkStatus() ending.

Nov 14 04:10:46 php-fpm 13000 /services_dyndns_edit.php: phpDynDNS (mullvard.den): (Success) IP Address Updated Successfully!

Nov 14 04:10:46 php-fpm 13000 /services_dyndns_edit.php: phpDynDNS: updating cache file /conf/dyndns_opt5porkbun-v6'mullvard.local'11_v6.cache: fc00:bbbb:bbbb:bb01::55:1d9a

Nov 14 04:10:46 php-fpm 13000 /services_dyndns_edit.php: Dynamic DNS porkbun-v6 (mullvard.local): fc00:bbbb:bbbb:bb01::7:1d9a extracted from local system.

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Dynamic DNS porkbun-v6 (mullvard.local): _checkIP() starting.

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Dynamic DNS porkbun-v6 (mullvard.local): _checkStatus() starting.

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Data: {"status":"SUCCESS"}

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header:

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header:

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: content-language: en-US, en

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: referrer-policy: origin

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: x-xss-protection: 1; mode=block

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: x-content-type-options: nosniff

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: x-frame-options: sameorigin

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: strict-transport-security: max-age=63072000; includeSubDomains; preload

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: pragma: no-cache

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: cache-control: no-store, no-cache, must-revalidate

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: expires: Thu, 19 Nov 1981 08:52:00 GMT

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: set-cookie: BUNSESSION2=zEIpulfKYtTr4NCC89MwjOrRSyb5SmOm-O1n%2CjlCVzg8tOHR; path=/; secure; HttpOnly; SameSite=Lax

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: server: openresty

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: content-type: application/json

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: date: Thu, 14 Nov 2024 04:10:45 GMT

Nov 14 04:10:45 php-fpm 13000 /services_dyndns_edit.php: Response Header: HTTP/2 200

Nov 14 04:10:40 php-fpm 13000 /services_dyndns_edit.php: Dynamic DNS porkbun-v6 (mullvard.den): Performing forced update. IP temporarily set to fd00:d:

[johnpoz]

@b3nw why would you have dynamic dns setup on an interface with a ULA? Are you saying there is a GUA on this interface and it keeps grabbing the ULA instead?

[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

is needed.
Look here.

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)