Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nested unloaded built-in "bogonsv6" alias within "Network(s)"-type alias treated like (invalid) URL #8212

Open
2 tasks done
pfry-git opened this issue Jan 12, 2025 · 2 comments
Assignees

Comments

@pfry-git
Copy link

Important notices

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

Describe the bug

The built-in "bogonsv6" alias has unique behavior: specifically, it is only loaded (populated) when at least one interface has "Block bogon networks" selected. The "bogonsv6" alias is selectable as a "Content" element within (at least) "Network(s)" type aliases (treated as any other "Network(s)" alias). If this is done, and the "bogonsv6" alias is not loaded ("Loaded#" under Firewall: Aliases is blank), the alias label "bogonsv6" is treated as a URL, and the system attempts (repeatedly) to query the element as a DNS name ("bogonsv6").

To Reproduce

As stated above, simply add "bogonsv6" to the "Content" of a "Network(s)" type alias and uncheck "Block bogon networks" under all interfaces. You can verify that "bogonsv6" is unloaded under Firewall: Aliases. Observe lookup failure under Firewall: Log Files: General and/or examine your nameserver's query log. Examples below.

Expected behavior

Given the standard loading/populating behavior of "bogonsv6", the expected behavior would be to treat the unloaded "bogonsv6" alias as empty (i.e. "Host(s)" or "Network(s)" type with "Content" field blank). I have preliminarily verified this configuration, but naturally have not tested it extensively. By its nature, I would not expect issues.

Describe alternatives you considered

Alternatively the "bogons" and "bogonsv6" aliases could be "disappeared" (made unselectable as "Content" within another alias), like the private networks aliases. Ideally they would remain visible under Firewall: Aliases.

Screenshots

You'll have to let me know if you want this.

Relevant log files

Sample named query log entries:

Jan 09 17:13:00 [named] 09-Jan-2025 17:13:00.255 queries: info: client @0x39630104c20 47.190.83.202#26515 (bogonsv6): query: bogonsv6 IN AAAA + (47.190.83.191)
Jan 09 17:13:00 [named] 09-Jan-2025 17:13:00.255 queries: info: client @0x39630240a70 47.190.83.202#42637 (bogonsv6): query: bogonsv6 IN A + (47.190.83.191)

Sample Firewall: Log Files: General entries:

2025-01-09T17:38:00-06:00 Notice firewall resolving 1 hostnames (0 addresses) for Martians_v6 took 0.00 seconds
2025-01-09T17:38:00-06:00 Error firewall The DNS query name does not exist: bogonsv6. [for Martians_v6]

Additional context

Comments only, not... immediately applicable to core bug...

The "bogonsv6" built-in alias behaves in some ways like a standard alias, and in others, not. Ideally these aliases could be created and manipulated using the standard alias mechanisms. Likely this would require some design work, as I doubt that the necessary elements are available within the current UI implementation.

As with any system grown over time, I could write a book on OPNsense UI and other design inconsistencies. Unfortunately most of these become embedded and are not easily addressed.

I would like to... be able to utilize the built-in aliases. Ideally the aliases would simply be available in the UI to nest within other aliases, that is the private aliases would be exposed and the "bogonsv6" alias could be loaded without having to apply unnecessary "Automatically generated rules". (Admittedly the private aliases are a minor issue as they are small and largely static.)

A less-than-perfect but potentially workable kludge would be to expose the content of these internal aliases as accessible URLs or files (although I do not see a standard file alias; I have not attempted to configure a file URL), so users who wished to filter on them could do so. I do not see a standard method to do this. Issue: Since this would not be a direct nest of the existing alias (data), it would duplicate the data, eating alias space.

Environment

I have not determined this. I imagine the "bogonsv6" implementation is pretty consistent. I would simply fix it in the latest development chains. Obviously not many folks (if any) have encountered this issue.

@AdSchellevis AdSchellevis self-assigned this Jan 13, 2025
@AdSchellevis
Copy link
Member

It sounds odd as all these dynamic aliases are implemented similarly, but I’ll put it in the list to double check. Which version is this by the way? Only development or also release?

@pfry-git
Copy link
Author

Hm. I replied to this via e-mail - I assumed it would post here. Guess I'll do it directly from now on. Content:

OPNsense 24.7.11_2-amd64
The loading/populating behavior of "bogonsv6" is unique, due to its size. It's a biggun.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants