Hello to the OPNsense community,
I´m new here, but I think I have found a bug in OPNsense 26.1.5.
The new IPv6 address assignment option "Identity Association" assigns a /63 instead of a /64 to the interface.
And also when I choose the 0x1 prefix, it also assigns a /63 which is not correct because the first /63 goes from `0000 - 0001`. So this wont work with multiple /63.
I´m looking forward to get informations if the bug is known already (I don´t found a forum topic about that) or not. :)
It does not do that per default. Identity association is the new version of the former "Track Interface". Thus, it depends on how many bits you have in your parent interface's prefix delegation size. AFAIK, you need a shorter than /64 prefix in order to be able to supply a full /64 prefix to any interface.
Maybe your ISP does not give you a /56 (which is pretty much the default) or you did not request as much on your WAN. How many bits is your IA_PD prefix?
Perhaps you should take a look at the official docs: https://docs.opnsense.org/manual/ipv6.html
Or my IPv6 guide (which is still based on track interface): https://forum.opnsense.org/index.php?topic=45822.0
Hi, thanks for the answer :)
This is a OPNsense in my lab and it gets a /60 from a higher router.
So there should be enough room for 16x /64 prefixes.
I looked at the WAN interface and I set it to request a /61 prefix, but get a /60. In this situation the OPNsense assigns /63 to any interface where I activate the IA. When I turn it to request a /60 prefix it works fine.
Why this behavior is there? That shouldn´t be like this I think.😅
IDK. If you feel that is a bug, create a bug request on Github.
Something appears to be rather broken with LAN prefix assignment in 26.1.x. I just attempted a new configuration from scratch (with the intent to document the process for my ISP's community). I have a /56 prefix delegation from the ISP. When my LAN interface is configured for "Identity Association", OR even when configured for "Track Interface (legacy)", it (the LAN interface) gets assigned the entire /56 prefix, where it should be given the first available /64. If I try to change "Assign prefix ID" to 1 (instead of 0) (shouldn't have to do this, but as a data-point...), it says that that's out of range.
@melectronics, did you open a bug for this yet?
Filed https://github.com/opnsense/core/issues/10070
I am using PPPoE and get a /48 prefix from my ISP.
On 26.1.5, I have no issues and it works exactly as it should.
Identity association on the LAN and I get a /64 with an Assign prefix ID of 0
I do "Request Prefix Only" on the WAN interface, and nothing else. (Apart from Prefix delegation size of 48)
Doesn't help you, but I just wanted to say it works perfectly for me.....
Actually it could have helped me, but we got there in the github discussion.
In my case, at least, the issue was (in part, at least) my failure to pay attention to the "Prefix delegation size" for the WAN interface. In my mind, this should be determined from the DHCP response, so I shouldn't have to configure it statically. Apparently when this setting is 64 (the default) it causes the prefix allocation for LAN interfaces to use the entire delegation (not sure why). So I think it's partly a user error, partly a shortcoming (should be automatic) and partly a bug (the weird end result).
Quote from: dseven on April 01, 2026, 02:27:30 PMIn my mind, this should be determined from the DHCP response, so I shouldn't have to configure it statically.
A good idea in theory (and some / most consumer routers do that), but for more advanced setups you really need to know the PD size in advance. For example, when configuring the subnet IDs of your LANs, you need to know how many bits are available. Let's say you configure a subnet ID 0x10 but then only get a /60... Things will break.
Cheers
Maurice
I suppose so. I'm currently focused on the "out of box experience" - i.e. I just want to plug in the credentials supplied by my ISP and I expect basic internet access (including IPv6) to "just work". It seems unfriendly that I have to configure something that seemingly could easily be derived from the DHCP response.
From what I've seen it's impossible to guess what the ISP will offer even more so if we specifically request something and the ISP ignores it.
We could fix the misalignment in dhcp6c, but then it's still pretty much broken in the core because it will make other assumptions.
Cheers,
Franco
Quote from: franco on April 08, 2026, 01:05:09 PMFrom what I've seen it's impossible to guess what the ISP will offer even more so if we specifically request something and the ISP ignores it.
We could fix the misalignment in dhcp6c, but then it's still pretty much broken in the core because it will make other assumptions.
How about more
"Advanced/Export Mode Finetuning Options" so to speak for
dhcp6c on the WAN Interface ?!
There's basic, advanced and override mode already... not sure what else would make sense.
Cheers,
Franco
Quote from: franco on April 08, 2026, 03:22:48 PMThere's basic, advanced and override mode already... not sure what else would make sense.
It sounded like he needed something that wasn't available yet, but since I have no direct experience with this kind of situation I will take your word for it :)
Nope, this is about behaviour of core, how it already configures dhcp6c and then the server does something else and wanting the core to make a better "guess" after the fact. From a procedural standpoint that's not trivial to integrate if it even makes sense in the overall architecture.
Cheers,
Franco
Quote from: Maurice on April 01, 2026, 04:43:00 PMA good idea in theory (and some / most consumer routers do that), but for more advanced setups you really need to know the PD size in advance. For example, when configuring the subnet IDs of your LANs, you need to know how many bits are available. Let's say you configure a subnet ID 0x10 but then only get a /60...
Doesn't sound like a real reason not to do it like most consumer routers do, to me. In my mind, OPNsense could be doing something better than the original but then refuses to do it for the same stubborn reasons.
So what magical thing do they do?
Consumer routers don't let you create an arbitrary number of subnets or manually configure subnet IDs at all. If all you have is one LAN and maybe a guest network, it's easy to handle a dynamic PD size. Just use subnet ID 0 for the LAN and 1 for the guest network. If you only get a /64, disable IPv6 for the guest network (or enable an NDP proxy).
We shouldn't do that level of automation in OPNsense. But the current workflow isn't ideal either. Many ISPs don't document their PD size. So you have to go to Interfaces / Overview, click the WAN interface's magnifying glass, scroll down to "Dynamic IPv6 prefix received" and then configure the PD size displayed there in the WAN interface's DHCPv6 client settings.
Franco, I think we once discussed the idea of a big fat warning somewhere in the GUI when the configured PD size doesn't match the actual PD size. I still think that would be a good idea.
Or maybe go one step further and actually change the config based on the actual PD size (optionally of course)?
Cheers
Maurice
> Or maybe go one step further and actually change the config based on the actual PD size (optionally of course)?
I do dread all of the dynamic-things-change-the-config.xml-state-which-changes-the-behaviour-of-the-firewall-further-by-triggering-a-required-reconfigure ideas. But that's just me. :)
> Franco, I think we once discussed the idea of a big fat warning somewhere in the GUI when the configured PD size doesn't match the actual PD size. I still think that would be a good idea.
We do have a banner facility that could read the respective PD info file and complain either everywhere or in the interface settings page specifically.
The biggest hurdle is still that interface pages are not MVC, but with the banner/notification system it's not so bad as it used to be.
Ticket would be a good start?
Cheers,
Franco