In all my VLANs my clients currently get a GUA address using SLAAC.
But for internal server communications I don't want to risk a prefix change from my ISP to break internal communications.
So, I've settled on using DHCPv6 to give out ULA addresses. Each server is given a dedicated address added to its host entry in dnsmasq.
Opnsense is given a ULA in each subnet as a virtual IP on each interface. In Router Advertisements the mode is set to assisted.
This partially works, as the clients get both a SLAAC GUA and the DHCPv6 ULA. However, since it's not possible to set RA modes per address, only per interface, I also get a ULA SLAAC address.
The extra address wouldn't have been a big deal if it wasn't for the fact that the servers use the ULA SLAAC as their source address when communicating across VLANs.
Because of that, my firewall rules, which rely on the hostname entries, kind of break.
The only "solutions" I've found are:
- Use the ULA SLAAC for source in firewall rules, but this is messy and the SLAAC may be using privacy extensions so the address is not deterministic (which is why I wanted DHCPv6 in the first place).
Disabling privacy extensions also makes the GUA EUI-64 and therefore exposes the MAC (not a deadly critical issue, but I want to avoid it). It also requires custom configuration depending on server OS, which I don't like.
- Use the whole network prefix as the source in firewall rules. This is what I currently do, but it makes my rules much "looser" than I would like.
The best solution would be if I could only set the RA A flag to only be used for the GUA prefix. But as I understand it that's not possible in Opnsense because settings apply to all addresses on the selected interface.
Or are there ways to do this that I just haven't found?
The "for all addresses in the interface" approach is also annoying with DHCPv6, because if I use the constructor and only specify the end addresses for the range, it will give out DHCPv6 for both GUA and ULA, when I only want the ULA. Specifying the whole range addresses solves this of course, but it's still a bit annoying.
Are there solutions to this issue? Am I just thinking about the whole thing in the wrong way?
Why not using good, old IPv4 for internal things?
A possible alternative would be to use ULA only for internal, and NPTv6 for internet...
Quote from: Bob.Dig on July 07, 2026, 09:33:24 AMWhy not using good, old IPv4 for internal things?
I am also fond of that, see: https://forum.opnsense.org/index.php?topic=45822.0 for an in-depth discussion.
Quote from: Bob.Dig on July 07, 2026, 09:33:24 AMWhy not using good, old IPv4 for internal things?
I could, but in the process of learning IPv6 better I wanted to run fully dual stack in the homelab. I don't think what I'm trying is too far outside of normal IPv6, so it should work.
If I'm doing something wrong I would like to learn what the correct way is.
With IPv6 you can set any number of addresses you wish, so it should be possible to add the ULAs in addition to the SLAAC GUAs. The only issue is that the GUI doesn't expose this feat (at all: even in the static configuration, it allows only exactly one IPv6 address to be set). I'm looking into disabling LLA autogeneration and instead manually assigning LLAs to match the ULAs so I can see which machine is burping in the logs without translating MACs all the time. But I need to enter two addresses for this to work though the GUI. Command line or script works of course, but it's a GUI-based system so...
Quote from: meyergru on July 07, 2026, 10:48:28 AMQuote from: Bob.Dig on July 07, 2026, 09:33:24 AMWhy not using good, old IPv4 for internal things?
I am also fond of that, see: https://forum.opnsense.org/index.php?topic=45822.0 for an in-depth discussion.
I get that, and technically I don't NEED IPv6 for internal communication.
It's an interesting exercise in understanding IPv6 better. As I understand it there is nothing "wrong" with my approach here, which is why it's frustrating that it almost works, but not quite.
I've finally had a chance to properly read through the thread you linked to, and there is a statement that I can't get to match with what I'm seeing from post 72:
"That is were ULA might be helpful. Then again, with dual stack, they will not be used when an IPv4 DNS entry exists."
But on my Debian machines it seems like ULA is prioritized over IPv4.
At least if I ping a host with both defined in DNS it's the ULA that's used.
Quote from: drosophila on July 08, 2026, 04:15:49 PMWith IPv6 you can set any number of addresses you wish, so it should be possible to add the ULAs in addition to the SLAAC GUAs. The only issue is that the GUI doesn't expose this feat (at all: even in the static configuration, it allows only exactly one IPv6 address to be set). I'm looking into disabling LLA autogeneration and instead manually assigning LLAs to match the ULAs so I can see which machine is burping in the logs without translating MACs all the time. But I need to enter two addresses for this to work though the GUI. Command line or script works of course, but it's a GUI-based system so...
You can add additional ULAs as virtual IPs on each interface.
Quote from: espenu on July 12, 2026, 12:38:44 AMQuote from: drosophila on July 08, 2026, 04:15:49 PMWith IPv6 you can set any number of addresses you wish, so it should be possible to add the ULAs in addition to the SLAAC GUAs. The only issue is that the GUI doesn't expose this feat (at all: even in the static configuration, it allows only exactly one IPv6 address to be set). I'm looking into disabling LLA autogeneration and instead manually assigning LLAs to match the ULAs so I can see which machine is burping in the logs without translating MACs all the time. But I need to enter two addresses for this to work though the GUI. Command line or script works of course, but it's a GUI-based system so...
You can add additional ULAs as virtual IPs on each interface.
Thanks for the info, though I don't see how this ties in with the ifconfig setup. The name suggests that the "virtual" addresses are in some way "lesser" than the "main" address. Maybe I'm wrong on this, I'd need to try it and see what ifconfig will end up looking like. I expect all sorts of breakage with this setup if I enter an LLA as "main" (since this should be available first) and the real ULAs as "virtual". Probably it all depends on how, when and where they end up getting set and this may even change on version upgrades. Maybe it's just a naming thing and all addresses get added in one swoop regardless of what they're called. I'll try once I can afford extended debugging downtime.
Edit: so I did some preliminary testing and my initial concerns seem to have been correct: the additional addresses are "lesser" than the primary address and do not get assigned at the same time / with the same priority. For reachability configurations this does not matter much, but the "primary" address is used for outbound connections and NAT, unless routing says otherwise or the addresses get reordered after the fact. For a static setup this is no problem, as I can simply assign my intended LLA as "primary" address and the true ULA as "alias". The system notices this and doesn't autogenerate another LLA even if auto-LLA is enabled. This, however, means that the global IP must be fully static, as the aliases support no dynamic assignments AFAICS, so either one must use GUA with a permanent prefix, or ULAs. This is OK on LAN, but is a real showstopper on WAN: an LLA assigned to WAN as alias is not assigned in time to allow SLAAC to use it, so I cannot disable auto LLA generation - which is the entire point of the exercise. Instead I end up with either an auto-LLA in addition to my own, or no dynamic IP address at all, as SLAAC won't have an LLA to work with when it is asked to negotiate. I'd therefore need a way to run SLAAC after the "alias" address is assigned instead of before - or have the aliases allow SLAAC so the primary address can be static. Of course, I can set up a script that removes the autogenerated LLA once the aliased one is assigned, but this would be yet another modification to keep in mind, track and reestablish on a fresh install.
It would be cool if the config backup would allow me to specify a list of additional files to include in the backup, so I could place such evil hacks there. :)
(again) ULA + NPTv6 seems like the obvious solution if you want to use ULAs internally with a dynamic GUA prefix for internet access. Have you even considered it? Hacks are likely to come back and bite you later...
Quote from: dseven on July 25, 2026, 10:05:28 AM(again) ULA + NPTv6 seems like the obvious solution if you want to use ULAs internally with a dynamic GUA prefix for internet access. Have you even considered it? Hacks are likely to come back and bite you later...
I'm using NAT66 so the dynamic prefix is no problem, neither are ULAs. This also is a supported configuration that works without hacks. The issue is that I want to get rid of the autogenerated Link-Locals (fe80) and replace them with manually assigned Link-locals (getting rid of them entirely
should work if a ULA is statically assigned, but at least OpenBSD refuses to create NDP entries from anything that is not fe80:0:0:0::; Windows, Linux and FreeBSD don't seem to care).
The hack I'd like to preserve has nothing to do with this, it is for the enforcement of the use of the privacy addresses for NAT66, which relies on the ordering of the address assignemts, so a script runs via cron to reorder them as there is no way to reliably hook into
actual change events.
I do not want two addresses, I only want one single address per interface. With IPv6, I cannot have that, so the addresses must at least be clearly coherent, which means that the LLA and ULA (and GUA, if used) must have the same suffix so logs will remain readable. But I cannot even do this, instead IPv6 insists on splattering and leaking the MACs all over the place. I'd even have run LLA-only if only NAT would be able to catch them before the kernel forcibly redirects them to localhost, nervermind the fact that NAT would take care of the scope violation (which it is all about, anyway).
It could have been so easy but instead it has to be overly complex to
enforce (not just allow) the idealistic doctrine (feels more like dogma) of universal reachability, that you then have to take pains to restrict in any meaningful way. :(
Sorry for the rant. :)
I guess my comment was directed at the OP. Your (@drosophila) use case seems quite different.
Quote from: dseven on July 26, 2026, 12:18:34 PMI guess my comment was directed at the OP. Your (@drosophila) use case seems quite different.
Maybe not so different, and to (finally ;) ) answer your question, I did briefly consider NPT but since that relies on the subnet sizes being identical (LAN and ISP), I've decided it to be better to go NAT66. That way I don't need to care about what prefix size the ISP hands me, so an ISP change would be fully transparent and not even require any configuration change. I feel NAT66 is the superior choice for this type of setup, even if it's unusual and commonly frowned upon due to what feels like ideology these days. :)
There is a very strong dogma that NAT66 is the devil itself (check out ipv6 reddit for example, they literally excommunicate people who even think about NATing IPv6).
In my opinion it just solves the same issue as NAT44 did, delegating the ownership of an IP address to a central device like a router. This is useful for Multi-WAN, dynamic DNS, VPN setups etc... and other kind of more specialized setups.
NPTv6 is harder to use, since e.g. in a SLAAC only network your router doesn't own the non-translated addresses and won't respond via NDP for them. There are ways to fix that but it's way more brute force than just using NAT66 instead.
Quote from: dseven on July 25, 2026, 10:05:28 AM(again) ULA + NPTv6 seems like the obvious solution if you want to use ULAs internally with a dynamic GUA prefix for internet access. Have you even considered it? Hacks are likely to come back and bite you later...
Sorry for the late reply to this post. I feel like NPTv6 itself is a hack though. Or, maybe not a hack, but it's still an address translation and veering away from the pure IPv6 setup that was my goal for this setup.
Quote from: drosophila on July 29, 2026, 02:46:57 PMMaybe not so different, and to (finally ;) ) answer your question, I did briefly consider NPT but since that relies on the subnet sizes being identical (LAN and ISP), I've decided it to be better to go NAT66. That way I don't need to care about what prefix size the ISP hands me, so an ISP change would be fully transparent and not even require any configuration change. I feel NAT66 is the superior choice for this type of setup, even if it's unusual and commonly frowned upon due to what feels like ideology these days. :)
Quote from: Monviech (Cedrik) on July 29, 2026, 03:01:11 PMThere is a very strong dogma that NAT66 is the devil itself (check out ipv6 reddit for example, they literally excommunicate people who even think about NATing IPv6).
In my opinion it just solves the same issue as NAT44 did, delegating the ownership of an IP address to a central device like a router. This is useful for Multi-WAN, dynamic DNS, VPN setups etc... and other kind of more specialized setups.
NPTv6 is harder to use, since e.g. in a SLAAC only network your router doesn't own the non-translated addresses and won't respond via NDP for them. There are ways to fix that but it's way more brute force than just using NAT66 instead.
I'm not quite in the camp of NAT66 being the devil. But it kind of breaks the intention of IPv6, and since my goal here is to have a working full dual stack while also learning proper IPv6, NAT66 feels like kind of a cheat.
By all means, it has its uses, it just doesn't align will my goals for this setup.
As I have understood it (and I'm still learning so I might be misunderstanding), the reason my setup doesn't work is due to the limitation in the Opnsense UI where setting up RA has to be done per interface, and it can't be tailored per prefix. So in this case both NPTv6 and NAT66 would be a workaround for an incomplete implementation (because it seems to have been an intentional design and not a bug).
The allure of perfection is quite strong for IPv6, if only the ISPs would have the same resolve and offer static IPv6 for all their customers like IPv6 intended...
That would be the most logical way to fix xD
ISP policy is the limiting factor at its root.
Agreed that (at least arguably) the root issue is ISP policy, but very few of us here are in a position to be able to change that.
Looking at radvd, AdvAutonomous is set at the prefix level, so it should be possible to have a ULA VIP on an interface that does not get advertised for SLAAC (but can be used for DHCPv6), which is (I think) what the OP wants. I wonder if it could be done by adding a flag to the VIP (interface config) to say "[don't] use this for SLAAC", then have the radvd config generation set AdvAutonomous for the prefix accordingly. That seems less complicated than trying to handle all of it in the RA UI. Not sure how much appetite there'd be for something like this in the dev camp (Hi Cedrik!) though ;)
The Router Advertisement config generation has some magic that has always been there and cannot be easily untangled anymore.
This means different settings for different prefixes on the same interface are indeed not possible.
But it's also not really needed most of the time, the most common setups can all be done:
A: GUAs + ULAs for all hosts
B: Only GUAs for all hosts
C: Only ULAs for all hosts
It also doesn't matter if hosts generate more than a single address for either GUA or ULA, it's common to have SLAAC and DHCPv6 addresses and privacy extensions. For me it doesn't make much sense trying to be smarter than necessary here.
The OP's issue is that they want to use static ULAs in their firewall rules. If SLAAC is in play, the addresses are not static, and that model breaks. They want "managed" for the ULA prefix and "assisted" for the GUA prefix (on the same interface).
If SLAAC is in play the addresses can be static too since they can be EUI-64 derived. SLAAC depends on the client configuration as well, like deactivating privacy extensions and other randomized SLAAC generation behavior, and only allow EUI-64 (or RFC 7217 stable addresses).
privacy/temporary addresses (RFC 4941 / RFC 8981) are entirely a host decision
The OP stated why they don't want to disable privacy extensions too (for the GUAs, used for internet access).
I don't want to keep arguing about it, but I do think there's some merit in the OP's request. Whether there's enough demand for it to justify spending development effort on it, I'm not sure....
Maybe dnsmasq can do it. You can configure different RA pools on the same interface with different flags from what I can see.
But I never tested that.
Quote from: Monviech (Cedrik) on July 30, 2026, 11:25:38 AMIf SLAAC is in play the addresses can be static too since they can be EUI-64 derived. SLAAC depends on the client configuration as well, like deactivating privacy extensions and other randomized SLAAC generation behavior, and only allow EUI-64 (or RFC 7217 stable addresses).
privacy/temporary addresses (RFC 4941 / RFC 8981) are entirely a host decision
That would require full admin access to all clients though (I mean, I do have that, but it might not always be the case).
I'm not trying to be difficult (not intentionally at least 😜), it's just that Opnsense is such a great system and it would be so great if it was possible to handle this type of setup (which I think is a completely valid use case), especially since the underlying systems actually support it and it's "just" a UI limitation.
I understand that it might be a narrow use case so no one wants to spend dev time fixing it, and that's fair. I will then just have to find a different approach to the whole stup, but at least I've raised the question 😊.
Quote from: Monviech (Cedrik) on July 30, 2026, 11:52:54 AMMaybe dnsmasq can do it. You can configure different RA pools on the same interface with different flags from what I can see.
But I never tested that.
I read somewhere that the same limitation was also present in the Dnsmasq RA, but I haven't actually tried it the way you describe. I will see if it's possible as soon as I have time to sit down and experiment.
Thanks.
Quote from: Monviech (Cedrik) on July 30, 2026, 11:52:54 AMMaybe dnsmasq can do it. You can configure different RA pools on the same interface with different flags from what I can see.
But I never tested that.
Out of morbid curiosity I set up DNSMASQ with SLAAC as the mode with the IP range of my ULA ffd0::1000 to ffd0::2000 (ULA truncated). I also set up ra-stateless for ::
Clients only seemed to get the slaac-generated IPs; the dhcpv6 ULA range did not assign a DHCP ULA address in the range above.
Happy to be wrong here in case I did a misconfigure, but manually-entered ranges including a prefix appear to be ignored for the use case of only defining a ULA range for dhcp. ::1000 to ::2000 without the prefix worked as expected, but only for the GUAs.
I'll double check my work and maybe open a bug report if needed, as the info tip for defining IP ranges does show a prefix (if defined on an interface of course) as a valid input for an ip range.
While you can syntactically do that and maybe the different RAs even get send out, I would not have expected it to work, because RAs are broadcasts, so they reach all clients. The mode flag determines if the clients should ask for DHCP offers. So, the clients will probably not request DHCP addresses once they see an RA that explicitely forbids them to.
I doubt that they would do that depending on specific ranges.
Quote from: meyergru on August 10, 2026, 09:02:53 AMWhile you can syntactically do that and maybe the different RAs even get send out, I would not have expected it to work, because RAs are broadcasts, so they reach all clients. The mode flag determines if the clients should ask for DHCP offers. So, the clients will probably not request DHCP addresses once they see an RA that explicitely forbids them to.
I doubt that they would do that depending on specific ranges.
Reaching all clients is fine and likely with OP is after (me too!). The use case here is to have clients assign a ULA via both DHCPv6 & SLAAC, with SLAAC alone for GUA. I can see the use case here given that ISPs do not keep GUAs and therefore internal addressing stable. Other issues of course persist with client preference.
I managed to have this same setup working with kea a while back and may resume it with one of the 3rd-party (non repo) ddns plugins that work with unbound to register leases. Keeping BIND happy was just too much effort. Here's the little plugin: https://github.com/JameZUK/os-kea-unbound/
Quote from: funtowne on August 10, 2026, 06:38:51 AMOut of morbid curiosity I set up DNSMASQ with SLAAC as the mode with the IP range of my ULA ffd0::1000 to ffd0::2000 (ULA truncated).
I'm fairly certain that it won't make a difference but a ULA is currently defined in the range of fd00::/8
Quote from: mooh on August 10, 2026, 01:23:18 PMQuote from: funtowne on August 10, 2026, 06:38:51 AMOut of morbid curiosity I set up DNSMASQ with SLAAC as the mode with the IP range of my ULA ffd0::1000 to ffd0::2000 (ULA truncated).
I'm fairly certain that it won't make a difference but a ULA is currently defined in the range of fd00::/8
That was a typo on my part, thanks for the nudge. The ULAs I have defined are indeed correct and sane. I'll leave the original post as is regardless.
@espenu - I think I have found a close enough solution after a bit of trial and error. I wanted a similar home setup with stable v6 and v4 addressing so win win! I use unbound for resolution and forward local network DNS queries to DNSMASQ. Here's the basic steps:
I'll use fd00::/64 as my sample range for this example, sub in your Prefixes as you see fit
1.) Set a ULA Virtual IP with a /64 on the interface(s) where you want ULA stable addressing. Reboot so that the IPs are correctly applied. I ran into an issue where rebooting was the only way to get this to apply correctly.
2.) Set RADVD to "assisted", configure other options as you see fit; set router advertisement prio to "high" in radvd
3.) In DNSMASQ set up a DHCP range for your interface(s) as shown below.
Interface: Your interface for the ULA assignment (eg: where the virtual IP is set).
Start Address: Set the ULA Prefix + Start address of your desired range (ex: fd00::1000)
End Address: Set the ULA Prefix + End address of your desired range (ex: fd00::2000)
Constructor: None
Prefix Length: 64
RA Mode: ra-names
RA Prio: Normal
4.) Reboot your clients to force soliciting new addresses if needed.
Set the rest of the settings for the lease time etc. as needed for your environment. The net result is as follows:
1.) My clients receive only SLAAC GUAs. The prefix assigned by my ISP is in practice not stable, thus DHCPv6 is not a great client option for the GUA. I also prefer radvd for announcements as it also sends a shutdown, deprecate and remove route announcement if a prefix changes. The shutdown, deprecate announcement and remove route options are configurable in the advanced settings.
2.) My clients also receive a SLAAC ULA and, if client is able, a DHCPv6 ULA.
3.) Local name resolution for IPv6 will only return ULAs. A lookup of a local client will return either the SLAAC IP, the DHCPv6 IP, or both.
Note: Enabling both SLAAC and DHCPv6 addresses for the ULA range covers all bases for clients' quirks to get at least one ULA address registered in DNS. For example, Apple devices prefer a "secure" SLAAC-generated IP which cannot be registered via ra-names, but the DHCPv6 address is registered since that is assigned by DNSMASQ. Some of my containers and other clients etc. are only SLAAC and will probably stay that way, therefore SLAAC addresses are registered in DNS for these clients and able to be resolved.
Quote from: funtowne on August 11, 2026, 01:41:11 PM@espenu - I think I have found a close enough solution after a bit of trial and error. I wanted a similar home setup with stable v6 and v4 addressing so win win! I use unbound for resolution and forward local network DNS queries to DNSMASQ. Here's the basic steps:
I've now finally had time to test and I can't get it to work as you describe.
Looking at the RA messages in Wireshark I can see RA's from both radvd and dnsmasq, and as long as one of them have "A=1" for the ULA prefix, the client will generate its own address in that prefix.
Note that also the only way I've managed to get Dnsmasq to send "A=0" is to enable "Router advertisements" under general and have nothing selected (Default) for RA mode in the DHCP range. The UI help states that "Setting Router Advertisement modes in DHCPv6 ranges will have no effect without this global option enabled.", but that's clearly not true, because setting anything in the DHCP range RA mode field will cause A=1.
Even if I get Dnsmasq to set M=1 and A=0 for the ULA prefix, radvd will come in and set A=1 for that same prefix. Turning radvd off for that interface will of course also mean no GUA SLAAC.
However, it works on your end, and I just don't understand how. Do you have any Wireshark logs of your RA messages that might help explain it?