Feature #15415
closed
Enhanced firewall log action information display
100%
Description
Currently hovering over the action icon on a firewall log entry shows a small tooltip with the action text and the rule tracker ID but it isn't clearly presented.
We should turn this into a nicely formatted box that appears when hovering, similar to the one used in other places for aliases, gateway groups, etc.
It should include at least the following:
- Action: <action text> (
$filterent['act']) - Reason: <reason text> (
$filterent['reason']) - Tracker ID: <id> (
$filterent['tracker'])
If it's viable, it might be good to show the actual rule there as well so users don't have to click to see it, but that may be slow/inefficient. If the rule can't be added, then the hover text should include a note saying "Click to show matching rule" or similar.
Files
Related issues
Updated by Jim Pingle about 1 year ago
- Related to Regression #15400: IGMP packets are logged when the filter rule has logging disabled added
Updated by Jim Pingle about 1 year ago
For users hitting #15400 who want to see the reason code ("ip-options" in that problem case), this diff will add it to the current tooltip:
diff --git a/src/usr/local/www/status_logs_filter.php b/src/usr/local/www/status_logs_filter.php
index f2e106fad0..4ae88f294b 100644
--- a/src/usr/local/www/status_logs_filter.php
+++ b/src/usr/local/www/status_logs_filter.php
@@ -188,7 +188,7 @@ if (!$rawfilter) {
$margin_left = '0.4em';
}
?>
- <i style="margin-left:<?=$margin_left;?>" class="<?=$icon_act;?> icon-pointer" title="<?php echo $filterent['act'] .'/'. $filterent['tracker'];?>" onclick="javascript:getURL('status_logs_filter.php?getrulenum=<?="{$filterent['rulenum']},{$filterent['tracker']},{$filterent['act']}"; ?>', outputrule);"></i>
+ <i style="margin-left:<?=$margin_left;?>" class="<?=$icon_act;?> icon-pointer" title="<?php echo $filterent['act'] .'/'. $filterent['reason'] .'/'. $filterent['tracker'];?>" onclick="javascript:getURL('status_logs_filter.php?getrulenum=<?="{$filterent['rulenum']},{$filterent['tracker']},{$filterent['act']}"; ?>', outputrule);"></i>
<?php
if ($filterent['count']) {
echo $filterent['count'];
Updated by Jim Pingle 11 months ago
- Plus Target Version changed from 24.07 to 24.08
Updated by Jim Pingle 7 months ago
- Plus Target Version changed from 24.08 to 24.11
Updated by Jim Pingle 7 months ago
- Plus Target Version changed from 24.11 to 25.01
Updated by Jim Pingle 5 months ago
- Plus Target Version changed from 25.01 to 25.03
Updated by Jim Pingle 3 months ago
- Plus Target Version changed from 25.03 to 25.07
Updated by Marcos M about 2 months ago
- Status changed from New to In Progress
- Assignee set to Marcos M
Updated by Marcos M about 2 months ago
- Status changed from In Progress to Pull Request Review
- Plus Target Version changed from 25.07 to 25.03
Updated by Marcos M about 2 months ago
- Status changed from Pull Request Review to Feedback
- % Done changed from 0 to 100
Applied in changeset 27db374dbca226f0429b1453802ff70764b3102d.
Updated by Jim Pingle about 1 month ago
- Subject changed from Enhance the firewall log action hover information view, show reason info to Enhanced firewall log action information display
Updated by Jim Pingle about 1 month ago
- Related to Bug #16093: Firewall logs mark entries for ``match`` rules the same as ``pass`` rules added
Updated by Jim Pingle about 1 month ago
- File clipboard-202503311006-wkfse.png clipboard-202503311006-wkfse.png added
- Status changed from Feedback to In Progress
Found a hiccup with the current output.
Sometimes a rule in the rules.debug gets expanded into multiple rules in pf. The current hover popup only shows the first matching rule (which may be same as before, I can't recall). However, it may not appear to be correct, even if it is.
For example:
Log entry:
Mar 31 09:59:40 jack filterlog[63907]: 91,,,1000005670,re1.50,match,block,in,4,0xc0,,1,7612,0,DF,17,udp,132,203.0.113.2,224.0.0.9,520,520,112
Hovering over that rule in the GUI shows:
Note: It's saying rule 88 matched, but the log shows 91, though the tracker matches. It's confusing to the user because the log entry is IPv4, but the rule it shows matches is for IPv6.
Looking at /tmp/rules.debug it shows:
: grep 1000005670 /tmp/rules.debug antispoof log for $WAN2 ridentifier 1000005670
But when you look at pfctl -vvsr it shows that pf expanded that one rule into multiple rules with unique rule numbers but using the same tracker ID:
: pfctl -vvsr | grep 1000005670 @88 block drop in log on ! re0 inet6 from 2001:db8:0:2::/64 to any ridentifier 1000005670 @89 block drop in log on re0 inet6 from fe80::20d:b9ff:fe33:f70 to any ridentifier 1000005670 @90 block drop in log inet6 from 2001:db8:0:2::14 to any ridentifier 1000005670 @91 block drop in log on ! re0 inet from 203.0.113.0/24 to any ridentifier 1000005670 @92 block drop in log inet from 203.0.113.14 to any ridentifier 1000005670
Seems like we should do one of the following:
- Check if the tracker ID and rule number match, if so, display that rule, not just the first match by tracker ID (fall back to only tracker ID if no matches on rule number?)
OR - Show all rules matching the tracker ID
Updated by Marcos M about 1 month ago
- Status changed from In Progress to Feedback
The following splits the rules found into "Matched Rule" and "Associated Rules". The matched rule shows the closest match of the rule which triggered the log. The associated rules show all rules with the same tracking ID: 738d2703ec4f483ea2d5038d4d6faa2f26a921b2.
Updated by Jim Pingle about 1 month ago
Looks good with that change applied.
One possible improvement might be to suppress the "associated rules" output if there is only one entry which is identical to the matched rule. When they are identical it seems slightly redundant.
Updated by Marcos M 30 days ago
Done with 823a344d6bbef2a598becaa1820da9981e6a0748
Updated by Jim Pingle 30 days ago
- Status changed from Feedback to Resolved
Works great with that change, now the redundant single associated rule is hidden, but it still shows if there are multiple matches.
Thanks!