Always use delegated prefix
-
There are a couple of places where it's necessary to manually configure the LAN prefix, even though pfSense is assigned one automatically. One is in OpenVPN IPv6 Tunnel Network, which provides the IPv6 address to be used by the remote device. The other is in the Router Advertisements Subnets, when a manually configured prefix is used, in addition to the delegated one. In that situation, the delegated prefix is no longer automatically provided. With this manual configuration necessary, a change in the delegated prefix will cause problems, until those settings have been reconfigured with the new prefix. Shouldn't it be possible to have both of those automatically configured for the delegated prefix?
-
In theory, yes, but practically, no. The client which obtains and assigns the delegated prefixes does not provide pfSense with a usable list of prefixes that can be used. It assigns them to interfaces directly. The code which accounts for the prefix in firewall rules/nat/dhcp/etc gleans the info from the interface and not from any data source containing the available prefixes.
Some work was happening to make that happen but I haven't heard about any progress in quite some time.
-
PfSense finds the prefix, out of the assigned block, when there is no manual configuration of a 2nd prefix on the LAN. Why is that not available when a 2nd prefix is created? Seems to me it shouldn't be hard to just save that first prefix somewhere, to be used when needed. Or, for that matter, just leave the automatic method as is, even when manually assigning a 2nd prefix. One example where this is really needed is when an ISP does not provided a consistent prefix, which means users have to change their local DNS, when the prefix changes. One way around that is to use unique local addresses. However, as soon as you create the ULA, you now have to assign the GUA prefix, which means IPv6 breaks, when the prefix changes. As for OpenVPN, since it's possible to select the prefix ID on interfaces and VLANs, why not also VPNs?
-
All good in theory but again, practically, it doesn't work as well as you think. We need to get the prefix info straight from the source but it doesn't provide that. Anything else is guesswork and calculation, or (worse) log scraping.
if it was easy, we'd have done it by now.
-
@jimp said in Always use delegated prefix:
We need to get the prefix info straight from the source but it doesn't provide that.
That already works, until you add a 2nd, manually configured prefix. Why does it break? For example, on my main LAN, I have the prefix ID 0 selected and that's what gets used, until I add a ULA prefix. I'm not asking that the ULA prefix be selected, only that the GUA prefix continue to be automatically selected.
-
That I'm not sure of. Check what ends up in your
/var/etc/radvd.conf
in that case. If bothprefix
sections look normal then it's probably still an issue inradvd
or even the clients. -
Here's the relevant (I hope) part:
prefix fd48:1a37:2160::/64 {
DeprecatePrefix on;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
AdvValidLifetime 86400;
AdvPreferredLifetime 14400;
};
prefix 2607:fea8:abcd:xyz::/64 {
DeprecatePrefix on;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;
};
prefix fd48:1a37:2160:0::/64 {
DeprecatePrefix on;
AdvOnLink on;
AdvAutonomous on;
AdvRouterAddr on;However, I had to manually configure both prefixes. I'm not sure why the ULA prefix is in there twice, as there's only one box to enter it. Perhaps the difference is the ULA prefix is derived from DHCPv6-PD, whereas the ULA is manually configured.
-
It looks to me like it's all part of the same (prone to bugginess) root issue. It has to determine the prefix info based off what's on the interface, and if you have that prefix configured on the interface (e.g. as an IP alias VIP or similar) then when it polls the interface to find the addresses to use, it picks that up instead of the delegated prefix. So the automatic part duplicates what you've entered manually.
-
My point is that since it already does it automatically, why doesn't it continue to do so, after a 2nd prefix is added? I'm not saying the 2nd prefix should be automatic, but the first one should be, since it already was. I assume that radvd.conf info was initially configured automatically. Why should it not be possible to simply add the 2nd prefix info to that file, without losing the info for the 1st? Why does the manual config for the 1st suddenly become necessary?
-
Further on this, the base prefix and prefix length are provided as part of the DHCPv6-PD process. The prefix ID is provided on the LAN config page. Why can the two not be used, if necessary, to automatically provide the first prefix?