Hi guys!
Sometimes we do things a certain way, just because we did it like that in the past. I am in no way immune to it :)
Anyway, I don't want to end up like people I see often, that don't use IPv6 or even suggest turning it off, just because I am stuck in the nineties with some ways of thinking.
And sometimes you think afterwards "how the hell did I do it in that bad way and wasted so much time on it" (me taking way too long before switching to public key auth).
So here are my questions:
1. IPv6 only
Is it time to go IPv6 only already? Like why bother with DHCPv4 and stuff? Just because of some sites? Why not just use NAT64 for these instead?
Currently it seems to me that enabling IPv4 is still the more foolproof. On the other hand, if you disable IPv4, some IPv6 misconfigs are easier to detect.
Like I was wondering why my Pihole was so slow. Turns out it first timed out for IPv6 (because of some misconfig) and then falls back to IPv4. That would not have happened without IPv4, then it would just not have worked.
2. DNS instead of static IPs
Currently I am still using static IPv4 for stuff like accessing Pihole VM over SSH.
Instead of just switching that to IPv6, I was wondering if this is obsolete anyway. Why not just use DNS instead?
3. Certs
For everything public I am using Certbot. But for internal stuff, I am using self-signed certs (intermediate CA). Simply because there is no Certbot for stuff like a Supermicro IPMI.
I choose certs to be valid for 10y. Some browsers like Safari, complain about the cert not being up to standard because of that long lifetime. Is there any other way of doing it the right way? I am hesitant on using DNS certs, since I fear the one compromise would compromise the whole setup instead of just one subdomain.
4. .internal instead of .arpa
I was under the impression that best practice is to use something like home.arpa.
Docs suggest that I should rather use something like home.internal
5. HSTS and .internal
Docs also recommend to use something like lan.internal.mydomain.com
But what if mydomain.com is preloaded for HSTS?
My guess would be that internal isn't excluded from HSTS?
But of course you could argue that everything should be encrypted, even local connections.
My NGINX reverse proxy uses http for some internal hosts.
6. Do you use DNSSEC for local recursive unbound?
I fail to say much security gains for my local recursive DNS unbound being recursive. Anyone using DNSSEC that points to their local unbound?
Quote from: JamesFrisch on May 16, 2025, 02:55:05 PM1. IPv6 only
Is it time to go IPv6 only already? Like why bother with DHCPv4 and stuff? Just because of some sites? Why not just use NAT64 for these instead?
Currently it seems to me that enabling IPv4 is still the more foolproof. On the other hand, if you disable IPv4, some IPv6 misconfigs are easier to detect.
Like I was wondering why my Pihole was so slow. Turns out it first timed out for IPv6 (because of some misconfig) and then falls back to IPv4. That would not have happened without IPv4, then it would just not have worked.
Most definitely not. Why? Because of your internal networks. This is especially true if you have an ISP who hands out dynamic GUA ranges.
It is a PITA to handle these with firewall rules and naming (see next section). ULA addressing can be done, but in that case, your devices all will have to deal with at least 3 IPv6s (link-local, ULA and GUA), if not 4 because of privacy extensions.
I covered most of this here (https://forum.opnsense.org/index.php?topic=45822.0) already. The gist of it is: use IPv4 for internal networking, with dual-stack GUA for outbound IPv6 access (preferably with IPv6 privacy extensions). For inbound access, a reverse proxy is nice, because it allows both IPv4 and IPv6 from outside, while haveing only IPv4 on the internal networks.
Quote from: JamesFrisch on May 16, 2025, 02:55:05 PM2. DNS instead of static IPs
Currently I am still using static IPv4 for stuff like accessing Pihole VM over SSH.
Instead of just switching that to IPv6, I was wondering if this is obsolete anyway. Why not just use DNS instead?
Yes, of course. That would be paramount for IPv6, because you do not want to memorize IPv6 addresses, or do you? I have it for all IPv4 as well. Also, there are a lot of aliases, like for docker services (behind traefik).
Quote from: JamesFrisch on May 16, 2025, 02:55:05 PM3. Certs
For everything public I am using Certbot. But for internal stuff, I am using self-signed certs (intermediate CA). Simply because there is no Certbot for stuff like a Supermicro IPMI.
I choose certs to be valid for 10y. Some browsers like Safari, complain about the cert not being up to standard because of that long lifetime. Is there any other way of doing it the right way? I am hesitant on using DNS certs, since I fear the one compromise would compromise the whole setup instead of just one subdomain.
I do that in much the same way. And read this (https://forum.opnsense.org/index.php?msg=236718) on why your certificates may not be accepted by some browsers. As it turns out, when you add a non-standard CA to a browser, long-lived certificates issued by those should work, but it depends on how you add them. You can have them start before 2020, because before that, long-lived certificates were allowed and are still valid.
Quote from: JamesFrisch on May 16, 2025, 02:55:05 PM4. .internal instead of .arpa
I was under the impression that best practice is to use something like home.arpa.
Docs suggest that I should rather use something like home.internal
Since you probably need DNS and matching certificates, you are free to use anything that does not collide with official TLDs. You could also use just one level, like xxx.internal. However, be aware that browsers do not accept wildcards with just one level like '*.xxx' - only '*.xxx.yyy'.
Quote from: JamesFrisch on May 16, 2025, 02:55:05 PM5. HSTS and .internal
Docs also recommend to use something like lan.internal.mydomain.com
But what if mydomain.com is preloaded for HSTS?
My guess would be that internal isn't excluded from HSTS?
But of course you could argue that everything should be encrypted, even local connections.
My NGINX reverse proxy uses http for some internal hosts.
You would use this if you main goal is to have ACME certs for your internal names. With your own CA, you do not need it and as you said, some devices cannot be provisioned by ACME anyway, so you still need your own CA for internal DNS. For that, why would you a. use long names (and you have to type them regardless of search domains because your certificates must match and b. use HSTS, because some devices do not support HTTPS.
Quote from: JamesFrisch on May 16, 2025, 02:55:05 PM6. Do you use DNSSEC for local recursive unbound?
I fail to say much security gains for my local recursive DNS unbound being recursive. Anyone using DNSSEC that points to their local unbound?
If you fear internal DNS poisoning... I do not.
If you're considering IPv6 with privacy extensions for outbound (as client devices may be want to do), you may run into an unresolved issue:
https://forum.opnsense.org/index.php?topic=44435.0
https://community.ui.com/questions/Unreliable-IPv6-temporary-address-generation/64ae65cb-f7d7-4a79-8bfc-c97efdc0005d#answer/555238e2-8705-410d-8f32-a231e1bbb4a5
https://community.ui.com/questions/IPv6-Privacy-Extensions-Broken-Temporary-Addresses-Not-Rotating-UDM-Pro/8aad42a8-d514-453d-8881-d6cc67f74ff5
QuoteMost definitely not. Why? Because of your internal networks. This is especially true if you have an ISP who hands out dynamic GUA ranges.
I have a good ISP. Good ISPs follow RIPE recommendations. AKA I get a static /48 prefix.
Are there any other points you see against IPv6 only?
I am not sure if can NGINX reverse proxy from my IPv4 WAN to an internal IPv6. Should be possible, will have to give it a try.
QuoteI do that in much the same way. And read this on why your certificates may not be accepted by some browsers.
Looks like I have to switch from Safari to Firefox for my homelab stuff then or try if Safari accepts certs from before 2020. Thank you for that tipp!
QuoteIf you fear internal DNS poisoning... I do not.
My neither. But to be fair, I also don't fear MITM attacks on my local network. So I am not sure if I even think that https is worth it internally.
Cheers for these great inputs.
QuoteIf you're considering IPv6 with privacy extensions for outbound (as client devices may be want to do), you may run into an unresolved issue:
I think I never had any problems with IPv6 privacy extensions. But you are making a great point on why to disable IPv4. I would not notice if IPv6 is broken. I don't use google, let alone ipv6.google.com for searches :) So without IPv4 I would notice it and could start to troubleshoot.
Quote from: JamesFrisch on May 17, 2025, 07:54:15 AMI have a good ISP. Good ISPs follow RIPE recommendations. AKA I get a static /48 prefix.
Are there any other points you see against IPv6 only?
Yes, I have old devices that can handle IPv4 only - and also Docker services. Handling IPv6 in Docker is extra hard and completely out of the question with dynamic prefixes anyway. Because of dynamic prefixes being the rule and not the exception in Germany, I would need IPv4 anyway, so I do not bother to find any complex solution like Nat for IPv6 just to enable internal DNS.
I do not want the complexity of going "full" dual-stack in my internal network (i.e. I use IPv6 only outbound).
Thus, with the choice of wanting to keep only one protocol for internal traffic, I still choose IPv4 over IPv6. If you have static IPv6 GUA and no more devices that would require IPv4, your choice might be different (but then: don't ever change your ISP!).
Quote from: JamesFrisch on May 17, 2025, 07:54:15 AMI am not sure if can NGINX reverse proxy from my IPv4 WAN to an internal IPv6. Should be possible, will have to give it a try.
Nginx can handle that, and Caddy and HAproxy can, too.
I don't have much to add. I have a question though: what do you guys use for your internal PKI?
Quote from: EricPerl on May 17, 2025, 06:27:34 PMI don't have much to add. I have a question though: what do you guys use for your internal PKI?
OPNsense ;-)
I use plain openssl, with a custom configuration in order to have a certificate start date < 1.1.2020. Also, my CA shows to be created before that date.
Quote from: Patrick M. Hausen on May 17, 2025, 07:32:25 PM...
OPNsense ;-)
I had looked at it and thought the documentation was sparse. I had missed the how-to though.
It does look like a lot of sensitive data ends up in the config file (thus also in backups).
I might accept this if other options fail or turn out too cumbersome.
Quote from: meyergru on May 17, 2025, 08:08:12 PMI use plain openssl, with a custom configuration in order to have a certificate start date < 1.1.2020. Also, my CA shows to be created before that date.
James mentioned an Intermediate CA so he might use something more sophisticated.
OTOH, you're obviously in total control.
I'm still doing some research.
I stumbled on this: https://github.com/smallstep/certificates?tab=readme-ov-file (https://github.com/smallstep/certificates?tab=readme-ov-file)
ACME compatible!
I might give it a shot (deployed on some VM).
Quote from: EricPerl on May 17, 2025, 09:41:16 PMIt does look like a lot of sensitive data ends up in the config file (thus also in backups).
I do backups to my own self hosted Nextcloud.
Any private CA needs to take special care of their private key, of course.
cheers guys for your answers!
I will try to run an IPv6 only network and switch from static IPs to DNS. Also switch from Kea to DNSmasq.
I have read that DNSmasq is only the new default for IPv4 (which I don't intend to use anymore) so I will stay with unbound for DNS.
Today I test migrated one of my VLANs.
This VLAN has two hosts, a Webpage and one network adapter of the NGINX reverse proxy.
This lead me to some new questions.
1. How would I access this host (ssh without the proxy) over DNS? When doing an nslookup -6 apache2.home.arpa I get a NX domain. Should unbound not have saved that? Do I have to add home.arpa to "Private Domains" under unbound advanced?
2. Even if unbound would answer me, which IP would it use to answer? Because the link local would not work for SSH, since I am in another VLAN.
3. Would it be smarter to use the GUA instead of DNS for NGINX proxy_pass? It is mostly static and not dependent on working DNS? Or why not go even one step further and use the link local IPv6? This one is even static if I change internet providers. And since my NGINX has interface in each VLAN anyway, it should be able to route that?
You are probably noticing a new bug that came up today with 25.1.7: https://github.com/opnsense/core/issues/8694
James appears to still use Unbound so it probably doesn't matter.
James, Unbound can supposedly deal with static reservations from all 3 DHCP servers but it needs to be restarted to pick up new entries.
Also, you did not answer my question about what you use for your PKI.
That is correct, I use unbound. But even after restarting unbound and the host, there is still no DNS entry for apache2.home.arpa.
I don't know what you are asking exactly about the PKI. I don't use proxies for that. I have a key pair for every host and the public keys are saved on github, simply because many OS allow you to import them from there.
The option with the fake valid from date was to bothersome for me, so I switched from Safari to Firefox for my homelab.
For KPI I did create a CA on a VM, created intermediate + certs. Then powered off. Obviously internal only. That was a few years ago.
I have toyed with the idea of using OPN instead when the time to renew comes along. It seems a neat piece of functionality to have there.
AFAIK, the prerequisite for DNS registration of STATIC mappings are:
* Unbound config to register
* Some DHCP server enabled
* Static entries defined for that server
* Static entries feature a hostname (if the domain name is empty, the OPN domain name is used)
* Unbound restarted after static entry update
I think I've seen a thread wrt entries not being picked up until the host requests the IP but I don't understand why it would be the case (given my understanding of the integration).
For PKI, I was referring to this in the OP:
QuoteBut for internal stuff, I am using self-signed certs (intermediate CA)
.
I was wondering what that meant. OPN? CA software on premises? something else?
Quote from: cookiemonster on May 20, 2025, 02:27:30 PMFor KPI I did create a CA on a VM, created intermediate + certs. Then powered off. Obviously internal only. That was a few years ago.
I have toyed with the idea of using OPN instead when the time to renew comes along. It seems a neat piece of functionality to have there.
Can you share the software used in that VM?
Most likely openssl.
Yes that's right, openssl.
The specific resource I always resort to when in doubt is https://www.feistyduck.com/library/openssl-cookbook/online/
For your own PKI is the chapter 15, and without OCSP so there is no need for OCSP responders. Feistyduck is my first go-to for all openssl doubts I have. Keep it in your pocket :)
Quote from: EricPerl on May 20, 2025, 08:31:17 PMAFAIK, the prerequisite for DNS registration of STATIC mappings are:
Ahh sorry, I don't mean static I mean the IPs that devices got from SLAAC.
Unbound can only deal with dynamic leases from ISC. The setting is "Register ISC DHCP4 Leases" for that reason.
Static leases are read from the OPNsense config...
...and they are being re-read only after an Unbound restart, different than dynamic leases.
Quote from: EricPerl on May 21, 2025, 06:15:13 PMUnbound can only deal with dynamic leases from ISC. The setting is "Register ISC DHCP4 Leases" for that reason.
Static leases are read from the OPNsense config...
Sorry for being dense, but does that mean that in a IPv6 only VLAN, unbound has no way of knowing clients?
Does that mean that device1.home.arpa will always get an IPv4 as response?
That is no dumb question: With Unbound and ISC DHCP, it seems so:
unbound_watcher.py watches /var/dhcpd/var/db/dhcpd.leases and shoves that into /usr/local/etc/unbound_dhcpd.conf, when a lease is detected.
There seems to be no equivalent for /var/dhcpd/var/db/dhcpd6.leases.
This also depends on how the clients get their IPv6 - with router advertisements, nobody would even notice a new device (at least for RADVD). Many clients, if at all, use DHCPv6 to get DNS info only, not to allocate them an IPv6.
But I thought that your ISP has static IPv6, so you can put any client, that you need addressable, into DNS statically.
So if I understand it correctly:
A default Ubuntu gets three IPs.
First one I can't use (is not static because privacy extension).
Second one has a static suffix, plus a static prefix, because the prefix from my ISP is static.
Third one is link local. Will not work over different VLANs.
So I could use the second or third one. But then I am back to the old IPv4 way of remembering IPs instead of using DNS.
Could I use mDNS instead? This should work out of the box without any changes from my part?
Would mDNS be stable enough to be used in a reverse proxy as proxy_pass?
Probably too risky, right?
You just let your system come up with whatever IPv6 GUA it gets from the ISP, then enter that in your DNS manually. Same for each internal SLAAC address of devices you want addressable and which do not use privacy extensions. Servers usually don't.
The addresses are configured automatically but static in nature, i.e. stay the same over reboots etc. So check what you got, enter that in DNS, done.
Cheers Patrick for your answer.
I think Ubuntu (netplan) does, but not Debian.
Hmm... Not really what I wanted to hear to be honest :)
If I have to enter the IP to my DNS manually, why even bother?
Just so I can enter the hostname into the proxy_pass instead of that IP?
Sounds like the same amount of work, but now my proxy is dependent on the DNS.
What I wanted to hear is:
SLAAC just like IPv4 watches for new DHCP leases.
But just like @meyergru said;
QuoteThere seems to be no equivalent for /var/dhcpd/var/db/dhcpd6.leases.
Which brings me to my next question.
Should I use DHCPv6 for these VLANs?
I again can't really find any advantages, am I missing something?
By assigning IPv6 with DHCPv6, my client gets a static IP, and this is hopefully also registered in the DNS.
But at the same time, my client gets a static IP anyway, so again, sounds like the same amount of work, but now my proxy is dependent on the DNS.
Is DHCPv6 only really useful, if you don't have a static prefix?
I only need DNS names for things I want to access as a server. And they are again pretty static in nature, they do not come and go.
Laptops and mobile devices - why bother naming them at all? You apply different security policies not by DNS name or IP address but by VLAN. All devices that should be treated the same go into the same VLAN. I don't care which is which.
Additionally I have Avahi on all my Linux and BSD systems, so e.g. "ssh pi1.local" works - and uses IPv6 😉
Quote from: Patrick M. Hausen on May 24, 2025, 11:58:22 AMLaptops and mobile devices - why bother naming them at all?
Because it's easier to debug. If I see "Foo's iPhone" in the tcpdump, I directly know what device it is. If I just see an ip address, I have to grep in the dhcp leases, what device it is.
I also only need DNS for things I want to access. Well not even then, to be honest. I want to reach my invoices tool, I use the public FQDN, which goes to my proxy. I am just unsure if that proxy should internally use an IPv6 or a hostname to proxy_pass the traffic.
Will take a look at Avahi, at a glance this looks like mDNS. Do you access only local devices or do you have some kind of multicast repeater on OPNsense running?
Avahi is mDNS. It is "the" open source implementation for that.
To work across VLANs you need a repeater, yes.
In reverse proxying I use IP addresses, but when accessing e.g. an internal UI or for monitoring with Uptime Kuma I use DNS. Manually created in cases where I want IPv6, but that's rare.
Internet --> IPv6 GUA --> Caddy --> e.g. Nextcloud via IPv4.
Quote from: JamesFrisch on May 24, 2025, 11:53:40 AMWhat I wanted to hear is:
SLAAC just like IPv4 watches for new DHCP leases.
But just like @meyergru said;
QuoteThere seems to be no equivalent for /var/dhcpd/var/db/dhcpd6.leases.
Which brings me to my next question.
Should I use DHCPv6 for these VLANs?
I again can't really find any advantages, am I missing something?
By assigning IPv6 with DHCPv6, my client gets a static IP, and this is hopefully also registered in the DNS.
But at the same time, my client gets a static IP anyway, so again, sounds like the same amount of work, but now my proxy is dependent on the DNS.
Is DHCPv6 only really useful, if you don't have a static prefix?
It seems you are finally getting to the same conclusions as me. I said most of this in my first answer and in the article I linked to.
Basically, it goes like this:
1. IPv6 cannot in all cases obtained through DHCPv6, so SLAAC is usually the best way to go. That also works for outbound access. I explained that here (https://forum.opnsense.org/index.php?topic=45822.0).
2. For inbound access and to address devices on your LAN, you would want DNS. But that works only in one of two ways:
a. By obtaining the DNS entry via a DHCPv6 request and registering it - at least,
theoretically, because that is supported by neither Kea nor ISC DHCP. Plus, see #1.
b. By putting the DNS name directly into DNS, but that is tedious and does not work for most people because of dynamic IPv6 prefixes, anyway.
And since IPv6 is not even supported by some devices (or services, e.g. on Docker) at all, you can eliminate all of these problems by just using IPv6 via SLAAC for outbound access and have your internal DNS IPv4-based. Your reverse proxy will take care of the rest, namely to translate from IPv6 on WAN to IPv4 on your LAN. The exception to this rule would be IPv6 services were a reverse proxy is not applicable. In those cases, you have to go with #2b, as Patrick suggested. Otherwise, he obviously takes the same IPv4-based approach as me (talking about "best practice" here).
To put it short: You are making it hard on yourself and try to remedy problems that you create by insisting to try "IPv6 only" without a good reason.
Thank you Patrick, really appreciate your answers.
Quote from: Patrick M. Hausen on May 24, 2025, 12:26:33 PMInternet --> IPv6 GUA --> Caddy --> e.g. Nextcloud via IPv4.
To play devils advocate here, why not use that static GUA IPv6 instead? Tried that with one of my services, worked great.
QuoteIt seems you are finally getting to the same conclusions as me.
I am a little bit slow :)
QuoteTo put it short: You are making it hard on yourself and try to remedy problems that you create by insisting to try "IPv6 only" without a good reason.
That is a fair point. My reason is not technical, but mostly for fun. My switch might be a little bit faster (nanoseconds) using IPv6 for the last part? Who knows? ;)
But what is cool about ditching IPv4 is that you need less stuff. Like a DHCP server. I am currently using ISC. Why not shutting it down, instead of migrating? Here is just one recent learning I got from doing that:
I was wondering why my invoice software shows an update but then times out trying to do that over the webGUI. Turns out it gets the update from Github. And Github is still IPv4 only :)
Quote from: JamesFrisch on May 24, 2025, 12:51:43 PMTo play devils advocate here, why not use that static GUA IPv6 instead? Tried that with one of my services, worked great.
Simple answer: SSL termination and certificate management. It's all in Caddy and all fully automatic.
All my public web services run through that single GUA and a single IPv4 address that way. Of course for e.g. Minecraft I placed the SLAAC GUA of the Minecraft server in its isolated VLAN into the public DNS.
Gotcha.
I do almost the same. All services point to my dual stack nginx.
I do SSL only on the Proxy and proxy pass http from there. Since the proxy and the service VM are the only two devices in their own VLAN, I don't see a reason why I would use SSL internally.