DynDNS with IPv6
-
I want to publish my (dynamically assigned by ISP) IPv6 prefix to my DNS provider. I use the custom(v6) service und %IP% within the URL is resolved to the actual pfSense IPv6 address. Thus the complete IPv6 address of my pfSense is published including the prefix but also the host part.
However I want to publish the prefix part only, i.e. excluding the host part of the pfSense box.
Example: If pfSense has 2001:db8:0:1::1111:11ff:fe11:1111 on the LAN I want 2001:db8:0:1:: to be published.
(Rationale: I have hosts in my network for which I need public IPv6 addresses. The host part of these hosts' IPv6 addresses are static and are configured in the DNS provider statically. So I need to add the dynamic prefix part.)
Of course I could have my IPv6 hosts do the job themselves however I would prefer my pfSense to have do this.
How can I do this?
-
How dynamic are your addresses? While my ISP uses DHCPv6-PD, my prefix hasn't changed in years. I just use a regular public DNS server.
-
@JKnott
While my ISP (Deutsche Telekom) does not force regular disconnects they do change my prefix after a disconnect like a reboot of pfSense. I have uptimes in the order of magnitude of months or even over a year.If there is no easy way with pfSense that's not a problem. I have a workaround in place but this is of the "fast and ugly" type (extract a global scope IPv6 address from an interface hoping there is only one and if not I get the right one by chance and pushing this to the DNS provider via an update URL, all of this with cron).
-
-
@johnpoz
This is actually already set however obviously ignored by my ISP.
-
@flo-0 what exactly is the use case here? So why can pfsense not just update its ddns with whatever its full IPv6 address is. And since your clients would have their own unique IPv6 address wouldn't they need to update their own ddns records?
Why not just let the clients update their own ddns? If their host part never changes, ok great - they would just be updating the prefix part of the address to whatever the new prefix is.. Still makes more sense to just let them update their address to whatever it is.
-
@johnpoz
If there are multiple hosts in the network for which this needs to be done then updating the prefix once through pfSense may be less complex than having each host do this by itself. Unless this is too complex to do with pfSense of course.I was looking for such an easy way. Something like %IPv6prefix%. But as I said: If there is no such way then this is not a big problem.
-
@flo-0 even if pfsense could do it - that ability would have to be with your ddns provider as well.
You could prob always script something up, but it would have to adhere to how the ddns provider wants the info to do such a thing.
-
@johnpoz said in DynDNS with IPv6:
even if pfsense could do it - that ability would have to be with your ddns provider as well.
This is actually the case. I'm using Dynv6.com. This allows to configure an ipv6prefix only and combines it with a separately configured host part. Very convenient.
Unfortunately the API for the configuration of a prefix accepts a complete /128 as well and configures a complete address. If it would only keep the first 64 bits I would be fine.
-
@flo-0 said in DynDNS with IPv6:
While my ISP (Deutsche Telekom) does not force regular disconnects they do change my prefix after a disconnect like a reboot of pfSense. I have uptimes in the order of magnitude of months or even over a year.
Do you need public DNS for those LAN addresses? Or just local? If local, you could configure Unique Local Addresses and use local DNS.
-
@JKnott
That's a very good question. This is part of a workaround. It's only remotely related to IPv6 at all.I want a totally simple thing: I want to be able to access servers via a browser from all stations in my LAN. Because I have multiple services on one machine (virtual servers) the accesses must be name based. Access by IP address is not sufficient. (Modern http protocol doesn't even allow address only access AFAIK.)
This was solved years ago with Bonjour / zeroconf. But nowadays browsers insist on https. Certificates for .local addresses are only possible when I create them myselves. However for browsers to accept such certificates I would need to provision the CA to all stations in the LAN. I don't want to do that.
So I registered a domain and use this internally like service1.mydom.com and service2.mydom.com. For these servers I can have Letsencrypt certificates created and provisioned to my servers. I register the internal IP address with an internal DNS override and all is well.
The next round in this folly game is the smart pants browser which decides to ignore my local DNS server. Not that I configured a browser to do such dumb stuff, they simply decide such things themselves nowadays. The result is that they don't find my local services anymore.
The next workaround is to make sure these servers' addresses can be found in public DNS. Whatever search algorithm these abominations of browser software employ: They will end up retrieving the addresses from the authoritative name servers for my domain. Pushing RFC 1918 addresses to public DNS is probably bad style (and whatever else). So I simply push the global scope IPv6 addresses of my servers to public DNS.
Now the browsers will find the global scope IPv6 addresses of my local servers and can access these in the LAN.
The good thing is that I don't need to make the servers accessible from the internet for this to work. To have the certificates created by Letsencrypt I don't use the webroot method but dns-01.
All of this does not work with Safari and Private Relay unfortunately. Safari with Private Relay can only access publicly available services. Of course I could break Private Relay in my LAN without changes to the connected machines. But I consider Private Relay a really good thing and I decided to keep it. So using internal servers is limited to browsers with less privacy.
Whether using local addresses would work really depends on whether these can be (and should be) configured in DNS. For the same reasons as with RFC 1918 I guess probably not. Means: No, this is not the solution to my problem.
-
@flo-0 WTF?
So you have zero need for IPv6 at all? Just access your devices via some dns you setup on pfsense.. Turn off doh in your browsers, its a click..
Access by IP address is not sufficient. (Modern http protocol doesn't even allow address only access AFAIK.)
Not true at all.. Here I am accessing my pfsense via https, and look at that my browser even trusts the cert.. Because I created the cert with the rfc1918 address in the SAN.
So all this is your attempt at a work around because you don't know how to turn off doh in your browsers and use local dns? Nor how to setup your own CA and create your own certs for your local resources? Or how to run multiple http services on your VM host using different IPs.. You have all of rfc1918 space at your fingertips.. Your host your running your services in on could have hundred of rfc1918 IPs and serve up different https services on all of them.
-
@flo-0 said in DynDNS with IPv6:
Whether using local addresses would work really depends on whether these can be (and should be) configured in DNS.
It most certainly will work. I do it here. Everything on my LAN gets a ULA address, which I put in the DNS.
Also, RFC1918 addresses work in DNS too. I also have them in my DNS.
-
@johnpoz
How on earth did you come to these conclusions about my knowledge level?? Of course I know how to setup a CA in pfSense. I have a CA running just fine since years. Three hosts in my network use it's server certificates. I know how to run multiple services as virtual hosts on one machine. I'm actually doing this on multiple machines (BSD and Linux) in my network. Of course I do use RFC 1918 addresses (who doesn't) and I'm totally aware of how I can assign private addresses.I just as well know how to configure a browsers to not use Doh. But I won't reconfigure other users' browsers.
You are correct in this assumption: I have no specific need for IPv6. Because I have as many public IP addresses as I need and I'm not forced to access any public services which are not available in IPv4. (I can't speak for my users of course.) This may however be the wrong mind set to look at IPv6 in general. This way IPv6 will probably never take the place it should have.
I WAS wrong about names mandatory for http protocol, thank's for correcting this.
