Feature requests

[Mr.Goodcat]

Hi,

based on my experience with OPNSense I'd like to suggest the following features:


• Predictable Network Interface Names
• Improved config file detection and restoration
• Access to all interface options from the GUI
• Option to remove configd.py from log file
• Excluding static DHCP leases from Services:DHCPv4:Leases when lease has expired / device is not active
• (Optional) IP resolving in the GUI and logfiles where appropriate
• Option to execute commands from the GUI
• Correct keymap on console
• Traffic Shaping: Priq Scheduler
• Traffic Shaping: Rules for entire Domains/AS (e.g. Netflix)
• Netflow: Merging Interface Statistics
• Netflow: Improved database repair
• Netflow: Overview of traffic stats by day/month/year
• Improved power efficientcy on AMD plattforms
• UEFI Boot

1. Predictable Network Interface Names, has the following benefits:

• Stable interface names when kernels or drivers are updated/changed.
• Stable interface names even if you have to replace broken ethernet cards by new ones.
• Stable interface names even when hardware is added or removed, i.e. no re-enumeration takes place. This is what broke my configuration and required quite a bit of manual reconfiguration on my part. Upon adding an additional NIC, interface names changed (i.e. the WAN interface igb0 was renamed to igb2), breaking LAN/WAN assignments, hence locking me out (as the interface going out to LAN was now assigned to WAN).

2. Improved config file detection and restoration:

• This may be hardware dependent, but on my system serveral usb flash drives with different file systems (FAT, ext4, NTFS) weren't recognized when installing OPNSense. Thus it was not possible to restore the existing config file directly during installation.

3. Access to all interface options from the GUI:

• As detailled in https://forum.opnsense.org/index.php?topic=7201.0 interface options available from the GUI can't be used simultaniously. In my case the "reject ip-address" statement is necessary as well as a "supersede" statement. Both are accessible from the GUI, but on different sub-pages. To use both options a modified dhclient.conf had to be created. This causes multiple problems. When restoring settings on a newly installed device the modified dhclient.conf has to be added by hand, instead of being part of the overall OPNSense config file. Also, the dhclient.conf explicitly references the non-unique interface name of the interface (e.g. igb0) and thus causes trouble in case interface names change (see item #1).

4. Option to exclude configd.py events from log:

• configd.py spams the log with events such as this, when viewing the dashboard: "configd.py: [2056dbe7-5bff-459b-adcc-4b49977b4077] request pfctl byte/packet counters". This makes it more difficult to search the log for important events and should thus be optional.

5. Excluding static DHCP leases from Services:DHCPv4:Leases when lease has expired / device is not active:

• Currently, the status of devices for which a static DHCP lease has been assigned are always shown as active in Services:DHCPv4:Leases. It would be helpful, if devices which haven't actually requested a lease or whose lease has expired are shown as offline. Thus one would be able to see how many devices are actually online.

6. (Optional) IP resolving in the GUI and logfiles where appropriate:

• Replacing IP addresses by cached/looked up host+domain names in the GUI and logs. This would be helpful to determin to/from which devices traffic is flowing, as one wouldn't have to check which device is using which IP.

7. Option to execute commands from the GUI

• Executing commands from the GUI would be helpful for tasks such as applying experimental patches.

11. Netflow: Merging Interface Statistics

• Recently I removed a NIC from my OPNSense Box, resulting in new interface names for the WAN/LAN ports. This causes the traffic data gathered under "Insight" in the "Reporting" category, to be inaccessible. While the data is still being shown in the plot (like in https://forum.opnsense.org/index.php?topic=7841.0 - in my case as "15" and "igb5"), the old interfaces can't be selected as the "top usage ports" and also can't be exported. Would it possible to update OPNSense to enable the selection/export of old, currently non-existant interfaces which are still contained in the database? Joing the data with new interfaces would be even better.

It would be great if these (small?) features could be implemented for a smoother OPNSense experience. As always, thanks to all OPNSense team members and contributors for their great work![/list]

[mausy5043]

May I add: (optional) IP resolving in the GUI and logfiles where appropriate.

* Replacing IP addresses by cached host+domain names in the GUI and logs.
* Replacing IP addresses by looked up host+domain names in the GUI and logs.

For local traffic I especially like to know where it is coming from/going to and I'm not very good in remembering which host is has which IP. Especially when using IPv6.
If logs and the GUI could show hostnames instead of (or together with) IPs that would also be very helpful. Seeing a host/domainname often gives a better idea of whether I need to be worried or not.

[Mr.Goodcat]

May I add: (optional) IP resolving in the GUI and logfiles where appropriate.

* Replacing IP addresses by cached host+domain names in the GUI and logs.
* Replacing IP addresses by looked up host+domain names in the GUI and logs.

For local traffic I especially like to know where it is coming from/going to and I'm not very good in remembering which host is has which IP. Especially when using IPv6.
If logs and the GUI could show hostnames instead of (or together with) IPs that would also be very helpful. Seeing a host/domainname often gives a better idea of whether I need to be worried or not.

Great idea! I've added it to the list if you don't mind.

[dcol]

I vote for #4 and #6
Also the following

- Make an allow rule from the firewall log. (Use to be there in Normal view). Or add back the Normal view.
- Have a live log for IDS too, like in firewall live view.
- Show the actual IDS rule in rule details.

Feature requests are more likely to be considered in github.

[franco]

Hi there,

1. It's difficult to anticipate what stable means. It looks like "do the right thing" in this context, but that is hard to code. Also we do not want to start looking into how the kernel names interfaces and why.

2. https://github.com/opnsense/core/issues/1372

3. https://github.com/opnsense/core/commit/d430a10 in 18.1.3

4. https://github.com/opnsense/core/issues/2067

5. Ticket please. This goes for all great ideas that will get lost in the forum, especially in replies.

6. General resolving is scraping IP addresses from the screen and resolving them. It does not sound like a feature. We do have Interfaces: Diagnostics: DNS Lookup, would a Reverse DNS Lookup be a useful addition?


Cheers,
Franco

[dcol]

Why was #4 removed from the milestone a day ago?

[franco]

It was moved to project "18.7"... currently experimenting with the new GitHub feature. Projects are nicer, because they can be shared across all repositories. But it seems only half-done. Maybe we have to put the milestones back. There are no shared milestones sadly.


Cheers,
Franco

[franco]

Someone on IRC mentioned that GitHub organization-wide projects are not visible publicly. So we'll have to put the milestones back. Sorry for the confusion.