firewall: global prefix in rules needs to be changed manually when IPv6 upstream prefix changes

[RyuunoAelia]

While playing a bit with NPTv6 I found a a workflow issue. The main and only reason to use NPTv6 is to avoid changing your local configuration (firewall rules, etc) when your upstream changes.

However, as things are done in opnsense right now, you need to manually update the NPTv6 rule each time the upstream changes.

This is fine for cases where you have complete control over when the prefix change occurs (multi-homed setup, etc). However, when the prefix may change without your knowledge (say a 6rd setup, or ISP providing ipv6 connectivity with short lived DHCP leases), having to manually update the rule painful.

I understand selecting the IPv6 might be problematic to implement in general. An interface may have multiple IPv6 at a point in time (even if you ignore link-local addresses). So maybe having a way to select on an interface if this interface will have dynamic NPTv6 rules might be a more straightforward flow for setting up things. But since I do not know much about the internals of the UI, I cannot give a pertinent insight.

My full context is described in #2538.

[fichtner]

This is also useful for DHCPv6 and SLAAC, but will require more tinkering.

[marjohn56]

With the manual addition we did to dhcpd6 it should change the prefix as the config for dhcpd6 has is re-written and re-loaded, that was always the bugbear, but I think that side is working. Whether it works when not using manual override (default) I did not test.

[fichtner]

Not for the rules currently. It doesn't allow tracking the interface prefix change.

[marjohn56]

So maybe we try splitting the rules into prefix/suffix..,, Alias for Prefix+suffix. It does make it complex for the user too, but that's the problem with a changing prefix, it's not for the faint-hearted.

[fichtner]

We already have a larger change in that area to make 6RD usable for "inet6" type rules and need to see if that is alright before we stack another layer on top, but generally an automatic prefix adaption option should be possible.

[chris42]

Having similar troubles discussed with marjohn56 in https://forum.opnsense.org/index.php?topic=9438.0

Being completely obvious on how technically the DHCPv6, SLAAC, RADV and the firewall works: Since the clients in the network negotiate their IPv6 couldn't Opnsense create a central register in the DNS, that is build during the negotiation process? This would keep the changing IP information centralized and up to date in realtime. (This would cover prefix changes as well as changes by e.g. privacy extensions)
Then you could use that register with Hostname in the firewall rules?

Basically using the Alias, but not having a 5min delay between resolving the hostname, but accessing the register (which should be up-to-date) of IPv6s in the network?

[fichtner]

Since we need to force a rules update on IP changes it's probably better to read the current IPv6 and merge the prefix accordingly and reload the rules. That should cover 99% of the use cases. The only tricky thing is integrating this logic and how to present it to the user (if applicable).

[chris42]

I would put an option next to the prefix delegation option to enable automatic prefix update to firewall rules. Then have in the Firewall rule next to the IP window an option to use delegated prefix. IP window then only holds the suffix part.
Then you could control if you actually want to use that feature next to the prefix delegation and then control per firewall rule, if it is a rule, that uses this feature.
Just to mark it: opinion.... ;-)

[RyuunoAelia]

To answer the "use hostname in rules" remark. It is not recommended by pf (the firwall software) documentation (because in general the firewall is started before any other services thus there is no DNS available to query).

The thing is, we don't need a convoluted thing like DNS, since opnsense (and pfsense for that matter) already regenerates all firewall rules when the IPv4 changes via DHCP, so we only need to have a way to map the IPv6 change too. With IPv6 it makes sense to split the network part and the machine part of addresses I think.
Event if both parts of IPv6 addresses can be dynamic since the internal network controls the machine part we can forget about it, and only concerntrate on managing changes in the network part (A.K.A. prefix).

The way I see things, you don't even need to change that much to UI, just make the IPv6 firewall rule editing look more like the IPv4 rule, with the drop-down list for Type of Source/Destination with a "Interface subnet" option and an optional "machine part of address" field or something like that. Then there's a bit of a tricky mangling of the input to regenerate the full address to pass to the pf command to do in the *.inc files.

[staeglis]

What's the current state of this issue? Will this be really solved in 19.7?

[cpw]

Is there anything I can do to help and or test anything?

[chris42]

This is quite disappointing. Together with the other IPv6 changes I was really looking forward to the 19.7
Now it is another 6 month.

[fichtner]

I'm happy to say to be disappointed by disappointment for lack of hands on deck on issues that are disappointing to be left disappointed in the first place. If nobody cares enough the community will go nowhere and disappointment is really displaced because there is a general lack of drive.

[chris42]

Than that is something that should be made public, that developers, funds, etc. are needed.

For me as a user, I cannot tell. I can only see the features that are rolled out and what is pushed back. IPv6 sadly/disappointingly the latter.

[fichtner]

No, as a user you can do better than simply share your subjective disappointment, especially on a major release day where a couple of things have been accomplished despite said disappointment.

[chris42]

I agree that the timing could have been better tomorrow.
Just see that I happily waited and tinkered with my setup for over a year now to get a proper IPv6 support. Something I cannot solve on my own, but need a developer to do. Until I saw your release E-Mail, I only knew it was tagged for 19.7 for half a year and came here to see, that it was moved 2 weeks ago.

So if you ask me to do better in communication, I will happily try to. But then it follows, that I ask you to do better in it as well and look into proper expectation management and tell us what Opnsense would need as support.

So I apologize for throwing my unfiltered disappointment out there. Please see it, as how much I like Opnsense and how much I want it to succeed. (there is no irony or sarcasm here)

[marjohn56]

@maurice-w - Thats not a problem - but you still need to be able to select the interface. ( head banging against wall repeatedly! )

[marjohn56]

Like this.

[marjohn56]

I'm almost there, just cannot get the Interface select to populate with anything...

[maurice-w]

@marjohn56 Yes, exactly. 'Interface' would have to be an interface with IPv6 configuration type 'DHCPv6', not 'Track Interface'. Agreed?
Entering ::2000 would be interface ID ::2000 in subnet 0. If you want interface ID ::2000 in e.g. subnet 1, you would enter ::1:0:0:0:2000.

[fichtner]

No, basically we just need primary IPv6 of the target interface to merge prefix. Still doesn’t matter how it got this address.

…

On 14. Apr 2021, at 15:55, Maurice Walker ***@***.***> wrote:  @marjohn56 Yes, exactly. 'Interface' would have to be an interface with IPv6 configuration type 'DHCPv6', not 'Track Interface'. Agreed? Entering ::2000 would be interface ID ::2000 in subnet 0. If you want interface ID ::2000 in e.g. subnet 1, you would enter ::1:0:0:0:2000. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[marjohn56]

@maurice-w - I see where you are coming from. So you would just increment the base prefix by one? Didn't you say you don't like doing that when we were discussing my auto dhcp6c ? 😉

[marjohn56]

Get's a bit complex for some too, they'd have to start being able to count in hex.

[marjohn56]

@fichtner - So what you see from what I've already done above, is that what you were thinking?

[maurice-w]

@fichtner, this would make it impossible to create aliases for subnets not assigned to an interface (downstream prefix delegation).
@marjohn56 Misunderstanding, these are just examples. I'm just saying that what you enter in the 'Content' field is not just the host's 64-bit interface identifier, but anything up to 80 bits (subnet ID + interface ID).

[marjohn56]

@maurice-w - In that case I would suggest that the suffix has to be entered is in its full form, so a suffix of 80bits is entered as a full address like so:- ::abab:3241:5318:adbc:ef12 , a 64 bit suffix would be ::3241:7977:adbc:ef12
We take that address, parse it, working out that length and then prefix it with the corresponding length of the prefix needed. otherwise anything entered will be assumed to be a 64 bit suffix.

[maurice-w]

I think we can just assume anything entered to be (128 - length($_pdinfo)) in length. If the delegated prefix you get from upstream is e.g. a /56, anything entered for the alias will be treated as 72 bits in length.

That's for host aliases, for network aliases it's a little bit more complicated.

[marjohn56]

That's not what @fichtner wants though is it? Look, I'll just carry on with the interface, once I've got that sorted we'll consider the merging.

[maurice-w]

If I understand @fichtner's suggestion correctly, I'm not sure how we could implement network aliases like ::40/60. I might sound like a broken record, but please consider downstream prefix delegation. If OPNsense gets e.g. a /56 delegation from upstream and delegates a /60 to a downstream router, we need to be able to add firewall rules for that /60 network. Otherwise, inbound connections to the downstream router would be impossible.

[marjohn56]

No look, I agree with you, I do it all the time testing from my primary down through my test router. I just want to get the alias edit stuff working first, then we can play with the merging, Got the alias edit working now with the interfaces, stupid typo... moving forward.

[marjohn56]

Erm, I think I've done it. :) @fichtner this is now in the rules.debug, is this what it should look like?

User Aliases

table <IPv6_Host> persist
IPv6_Host = "<IPv6_Host>"
Tst_IPv6_Dynamic = "{ 2a02:8010:6228:f600:0:0:0:2000 }"

[marjohn56]

Apparently so, my prefix changed and so has rules debug. I'll tidy it up and PR it for playing with. In its current state it just merges the prefix with the suffix, with a little bit more work @maurice-w we should be able to merge any prefix lengths etc.

[marjohn56]

First commit #4919

[TheRealBecks]

What's the next step here?

[TheRealBecks]

#5284 and this one are stalled :( Or are you waiting for #5574 to be pulled in?

[fichtner]

#5284 has been shipped. It's still not perfect but will continue the work in #6158

[kathampy]

Can this be enhanced to match a /64 subnet instead of just a single host? I need to create rules for entire subnets from a downstream L3 switch.