Dynamic DNS client "extracted from local system"
-
@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.
-
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.
-
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?
-
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.
-
@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?
-
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.
-
@stephenw10 true - but if it something that has to be setup specific in pfsense to account for this sort of unique setup..
-
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.
-
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.
-
@stephenw10 https://redmine.pfsense.org/issues/11177 links to a non-resolvable gitlab PR, is there another one?
-
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.
-
@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)
