opnsense / core

OPNsense GUI, API and systems backend
https://opnsense.org/
BSD 2-Clause "Simplified" License
3.27k stars 727 forks source link

firewall: option to create a dynamic IPv6 prefix network alias #7000

Open subnetspider opened 10 months ago

subnetspider commented 10 months ago

Important notices

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

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

grafik

doktornotor commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

@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 https://github.com/opnsense/core/issues/6902 . I think we also need to add the toggle in the documentation by the way.

doktornotor commented 10 months ago

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

BPplays commented 1 month ago

@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.

under 5. End-user IPv6 prefix assignment: Persistent vs non-persistent it says:

It is “persistent” for the same customer in the same link/location regardless of the provisioning system being used.

i feel supporting dynamic prefixes would still be needed because prefixes are ISP and region specific and not owned by a person so if you ever move your prefix will change.

even if your ISP did something like keep prefixes for a customer even with a location change i doubt they're allowed to do that across RIR boundaries even if they operate across regions, and not to mention one ISP might not be the best choice in a different location.

fichtner commented 1 month ago

I don't disagree with this. It would, however, be much nicer if pf(4) did it natively if it was such an important feature.