Add private network exclusions to default IPv6 bogons

[maurice-w]

Issue fixed by this: When setting up a new system with only a single interface (WAN only), 'block bogon networks' is enabled by default on this interface. Since bogonsv6.sample blocks 8000::/1, accessing the web GUI from ULAs and link-local addresses isn't possible. If the WAN is IPv6-only and doesn't have GUAs (yet), you're essentially locked out from the start.

[AdSchellevis]

It might be better to split the ranges, these exclusions have side affects when stacking aliases, which can then lead to unexpected behavior when the bogons aren't updated later on. If I'm not mistaken, our distributed list doesn't use the exclusions anymore, because otherwise that would also be an item still on the list somewhere.

[fichtner]

Yes, see #9048

[AdSchellevis]

@fichtner I remembered there was "something" ;) when needed, I can still pre-process the list on our server to simplify handling, but no rush at all.

[maurice-w]

@AdSchellevis @fichtner Alright, I split 8000::/1 instead (and didn't bother with ::/128).

[maurice-w]

Ping @AdSchellevis @fichtner
Anything else you'd like me to change before merging this? I split 8000::/1 so that fd00::/8 and fe80::/10 are excluded. That's what you suggested, correct?

[fichtner]

The filtered bogons file from the mirror currently does this differently:

@@ -3,7 +3,5 @@
 e000::/4
 f000::/5
 f800::/6
+fe00::/7
 fc00::/8
-fe00::/9
-fec0::/10
-ff00::/8

Ideally I'd like to use the same for both files... is this equivalent (sorry I don't have time to check right now)

[maurice-w]

The bogons file from the mirror blocks fe00::/7. We then unblock link-local in OPNsense by adding !fe80::/10.

I used fe00::/9, fec0::/10 and ff00::/8 instead, which is fe00::/7 minus fe80::/10.

[fichtner]

ok then there's a problem in the split of the subnets in the bogons file creation... I'll check

[AdSchellevis]

I don't think fe00::/7 is still in https://team-cymru.org/Services/Bogons/fullbogons-ipv6.txt, which might explain the omission.

[fichtner]

No, this is about 8000::/1 which both fd00::/8 and fe80::/10 belong to. If I reverse the exclusion I get a list that morec closely resembles @maurice-w suggestion, but even then fe00::/7 is still in that list

[AdSchellevis]

If you need an extra pair of eyes on the script, just let me know

[maurice-w]

In terms of quality control, it might be beneficial if the script which creates the bogons would be public. Or is it and I just haven't found it?

[AdSchellevis]

it's part of our internal processing, no need to publish it online.

[maurice-w]

Understood. But be aware that this makes the published bogons.txz the reference for contributors, which we have to assume is correct. No way for us to know whether something on these lists is intentional or not.

[AdSchellevis]

That's true, but the same is the case for all other pieces of content to be honest (like geo data), one could argue something is missing or too much, but that claim should always be guarded with some evidence, how the file was constructed is less relevant in that case.

[maurice-w]

The difference being that the bogons undergo additional processing on OPNsense itself. This second step is the only one which is transparent to contributors, which makes it harder to pinpoint issues. Are they caused by your internal preprocessing or by OPNsense or both?

But I understand you are moving away from additional processing on OPNsense, which improves the situation.

[AdSchellevis]

Multiple layers of processing clutter the view indeed, which is what we're trying to solve here, ideally the contents of the alias are exactly the same as being offered (which is the same for other feeds as well, either offered by us or third parties)