Interface:"Block private networks" and "Block bogon networks" does not work properly with ipv6.

[IsaacFL]

Important notices

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

• [X ] I have read the contributing guide lines at https://github.com/opnsense/core/blob/master/CONTRIBUTING.md
• [X ] 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

Describe the bug

Blocking bogons blocks ipv6 private ULA addresses even if "Block private networks" is not checked. This is not consistent with behavior of ipv4 block bogons.

The problem is in the script located at:

/usr/local/opnsense/scripts/filter/update_bogons.sh Line 77 egrep -iv "^fc00::/7" ${WORKDIR}/fullbogons-ipv6.txt > ${DESTDIR}/bogonsv6

The script is trying to remove the ULA address from the downloaded bogon list, like it does for ipv4 bogons, But this will not work for ipv6 as the source bogon list has a single entry of 8000::/1. This entry blocks the entire upper half of the address space (including ULA), instead of individual ranges like fc00::/7.

So effectively the ipv6 Private ULA address space is always blocked with bogons and is not consistent with ipv4.

Instead of grepping for fc00::7, I would recommend just adding "!fd00::/8" to the end of the bogon list. The lower half, fc00::/8, is currently not defined so it truly is a bogon.

This issue is primarily about bringing consistency between ipv4 and ipv6 in the ULA space, but I would also recommend adding the link local address "!fe80::/64" as an exception. I don't see how the link local should be treated as a bogon, when it is allowed router to router and causes a lot of probably not expected blocks if you block bogons. The rest of the fe80::/10 is a bogon, since it is reserved but undefined.

To Reproduce

Steps to reproduce the behavior: If you enable block bogons, but not block private on an interface with logging on, you will see the using ULA is getting blocked by block bogons rule.

Expected behavior

You should be able to block bogons, but still use ipv6 private addresses unless Block Private is also enabled. Just as in ipv4.

Describe alternatives you considered

Currently I create my own alias, that is just the bogonsv6 with added !!fd00::/8, !fe80::/64 and create floating rule instead of using block bogons on the interface. This does work, but you now have duplicated a very large table, so is not optimal solution.

Screenshots

NA

Relevant log files

NA

Additional context

NA

Environment

Software version used and hardware type if relevant, e.g.:

I am using latest version but this has been an issue as long as I have used opnsense.

OPNsense 23.7.2-amd64 FreeBSD 13.2-RELEASE-p2 OpenSSL 1.1.1v 1 Aug 2023

[fichtner]

I think the upstream provider changed the bogons layout to reduce file size perhaps. I'll take a look but it can take a while if we need to rewrite what they send now.

[fichtner]

PS: The concept of "private" outside of "bogons" which includes private is a bit sad to be dragging it around all these years because someone thought it was a good idea.

[IsaacFL]

Yes, It would require more rewrite but a more appropriate approach would have been an option to block all bogons with no processing of the downloaded list, with an option to "PASS" private addresses that occurs prior to the block bogons for both ipv4 and ipv6.

[IsaacFL]

But you can't do that cause you would be allowing all private address traffic.

[fichtner]

it would perhaps work with a non-quick rule as long as the default deny is quick, but possibly breaking some rule constructs anyway :/

[IsaacFL]

I have not found a working way to do that even by downloading the list directly. It always seems to come back to adding the exclusions (!fd00::/8, !fe80::/64) to the bogon list. It just doubles the table size, a large one at that, when I do.

[fichtner]

Shouldn't that be !fe80::/10? Does the table size doubling persist then?

[IsaacFL]

No, I'm just creating an my own Alias "BOGON_V6" that has the contents of the bogons, with added exclusions. i.e.

"BOGON_V6" Contents: !fd00::/8, !fe80::/64, bogonsv6"

So I end up with another alias the same size as the bogonsv6.

I don't know if you can just add exclusions to the end of the bogonsv6 as part of the download and creation of the alias?

So doesn't matter the size of the exclusion as far as I can tell. I'm not trying to bust up the 8000:/1. The exclusions just get added to the end of the alias.

The reason I use the more restrictive, fe80::/64 vs the fe80::/10 is that fe80::/64 is the only legal use for link local. The entire fe80::/10 was reserved, but the lower 54 bits of the prefix are defined as "0" only. So all of fe80::/10 except the first fe80::/64 truly is a bogon and should never be used for Link Local Addresses.

https://datatracker.ietf.org/doc/html/rfc4291#section-2.5.6

Same thing with the ULA /fd00::/8 vs fc00::/7. The fc00::/8 half was deprecated.