You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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?
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.
The text was updated successfully, but these errors were encountered: