firewall: option to create a dynamic IPv6 prefix network alias

[subnetspider]

Important notices

Before you add a new report, we ask you kindly to acknowledge the following:

• I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• I am convinced that my issue is new after having checked both open and closed issues at https://github.com/opnsense/core/issues?q=is%3Aissue

Is your feature request related to a problem? Please describe.

Currently, there is no easy way to create firewall rules to block or allow traffic to and from specific IPv6 subnets with dynamic global unicast prefixes on OPNsense because the global unicast addresses are all in the 2000::/3 range.

It is also not trivial to restrict an IPv6 subnet with global unicast prefix to access only the IPv6 Internet (2000::/3), but not other internal subnets with dynamic IPv6 prefixes (also 2000::/3).

Since the __opt_#_network aliases ($interface_name net in the firewall editor), which contain all IPv6 prefixes on the given interface, cannot be nested inside other aliases, it takes as many firewall rules as there are IPv6-enabled subnets to restrict e.g. servers in a DMZ subnet from talking to clients in the LAN subnet.
With a large number of IPv6 enabled subnets/VLANs on OPNsense, this becomes difficult to scale very quickly.

Describe the solution you like

I would like to see the option to create an alias of type "Dynamic IPv6 Prefix", which works like the "Dynamic IPv6 Host" alias, but with the difference that there is no "Content" field for the interface identifier / last 64 bits.

It would work exactly like the "Dynamic IPv6 Host" alias, but with a /64 mask instead of a /128 mask.

Adding the choice to specify a custom prefix length other than /64, such as /48, /52, /56, or /60, would also be useful in some cases, but might be difficult to implement.

Describe alternatives you considered

Alternatively, this functionality could also be implemented by allowing the __opt_#_network aliases mentioned above to be nested within other aliases, since these already exist, but are only used internally by OPNsense.

Additional context

[doktornotor]

May I suggest that you use NPtv6 and move on? The documentation on aliases provides a good hint why this is not exactly viable and would produce just a giant mess. I mean this part:

Let’s take another example, you have a /48 prefix delegation, you have two LAN interfaces and a server on each. You would need to create two separate Dynamic IPv6 Host entries, one for each LAN. For simplicities sake we will use the same address for each server on each interface, you would enter ::aaaa:bbbb:cccc:0001 as the address.

IOW, what works in pf rules does not work in aliases. This request did not get anywhere on the other project either,

[fichtner]

Promised to look at this again. Suffix support (::xxx) in pf.conf would be the best thing but we can't have that and people do need this silly stuff due to ISPs doing dynamic PD. Just to make it clear this is about a "network" alias for the dynamic prefix.

[doktornotor]

Yeah, when messing with this, eventually it ended up with one "dynamic" alias per subnet (interface) -- which is basically the same as one rule per subnet. Not pretty at all, automated behind the scenes or not. With a "dropdown" for source / destination, perhaps. Any attempts on allowing nesting with custom aliases - well, just yuck, abandoned that very quickly.

[subnetspider]

people do need this silly stuff due to ISPs doing dynamic PD.

Exactly, if ISPs had implemented IPv6 according to the recommendations of e.g. RIPE NNC, this would not be an issue.

If it turns out that it's not possible to solve IPv6 inter-VLAN firewalling with dynamic IPv6 prefix aliases, could this be solved with Set local tag and Match local tag (Rules - OPNsense documentation) together with floating firewall rules?

[doktornotor]

Tagging, yeah why not... Would be even more flexible if the match option had an "invert" checkbox. @fichtner - possible to add that one?

tagged <string>
	     Used with filter, translation or  scrub  rules  to	 specify  that
	     packets  must  already  be	 tagged	with the given tag in order to
	     match the rule.  **Inverse tag matching can also be done by speci-
	     fying the ! operator before the tagged keyword.**

[AdSchellevis]

@doktornotor adding an invert isn't a huge issue, but a small write-up to document in which case this would be practical would be helpful (preferably in a new ticket). We did something similar for the floating rules in #6902 . I think we also need to add the toggle in the documentation by the way.

[doktornotor]

Yeah, the tags are useful for more things that this - e.g. this forum thread on DNS redirection.