Firewall Rule Numbers
-
Is there an easy way to track back the number i.e. (1000000114),
which appears in the rule column of the "Status: System logs: Firewall" to the actual rule that blocked it?I can't seem to work out how to match a firewall rule to the numbers that appear. :(
Thanks
Rob
-
Click on the red X at the far left and it will tell you the rule that blocked that packet.
-
Ah ok thanks, i moused over that and it looked like it would block the rule so i didn't click it.
After clicking it its still not really clear.
Is there anyway i can create alias's or something so instead of just a number it would appear like this one "Default deny rule IPv4 (1000000103)"?
-
Not that I know of. The Default Deny rule is an invisible rule at the very bottom of each firewall rule tab that essentially blocks everything. So, if a packet comes in and doesn't match any allowed traffic (parsing the rules top-down), then it is blocked by default by this hidden rule.
-
Uhm… In settings, enable the Filter descriptions, select display as column from the dropdown and be done with that?
-
In settings, enable the Filter descriptions
Thank you!
Hmm, after trying it, it would be much more helpful if it would make use of the descriptions that you attach to every rule. All I get are the Default Deny and then just a list of numbers in brackets.
-
I somehow thought it was the default?! (Kept wondering why everyone keeps posting screenshots with those unreadble rule numbers.)
-
Yeah not every rule shows its description as i have them in column view but i still get rules that i would have to work out which rule caused it. If it just displayed the rule description for all rules in column or second row view it would be much better.
-
Perhaps post a screenshot? Does not happen here.
-
My firewall log shows both the rule description and rule number. Only time I've know it to show just the rule number is for firewall rules that are disabled or deleted.
-
The description is shown where one exists. If you have a number only, it should only be because it's being logged by a user-defined rule with a blank description. Or possibly the deleted rule scenario NOYB mentioned if you removed some rule(s).
-
Just verified that a disabled (not deleted) firewall rule will also result in the description no longer being displayed in the firewall log. Upon re-enabling the rule the description is again displayed in the firewall log.
2.2.3-RELEASE (i386)
built on Tue Jun 23 16:37:33 CDT 2015FreeBSD 10.1-RELEASE-p13
-
Well yes, cannot get a description where it doesn't exist in the active ruleset. ;)
-
Ok thanks I've toggled column view a few times and it all seems to work but they root of my problem seems to be just one rule that will not show a description. All the rules on the OPT1 interface have a description but i think i will just have to work it out manually which was what i was hoping to avoid.
Also at the command line running pfctl -vvsr give mess this relating to that number
@40(1000000114) block drop log quick inet proto tcp from any to any port = 0
[ Evaluations: 5321224 Packets: 4737 Bytes: 284220 States: 0 ]
[ Inserted: pid 73290 State Creations: 18446735277732176120]
@41(1000000114) block drop log quick inet proto udp from any to any port = 0
[ Evaluations: 5316129 Packets: 4737 Bytes: 284220 States: 0 ]
[ Inserted: pid 73290 State Creations: 18446735277732176096]Although I'm no clearer where this rule has come from.
Thanks for replies.

 -
Ok thanks I've toggled column view a few times and it all seems to work but they root of my problem seems to be just one rule that will not show a description. All the rules on the OPT1 interface have a description but i think i will just have to work it out manually which was what i was hoping to avoid.
Also at the command line running pfctl -vvsr give mess this relating to that number
@40(1000000114) block drop log quick inet proto tcp from any to any port = 0
Well that does not have any label, it's this stuff in https://github.com/pfsense/pfsense/blob/master/etc/inc/filter.inc#L3157
Try this with System Patches package:
--- a/etc/inc/filter.inc +++ b/etc/inc/filter.inc @@ -2876,10 +2876,10 @@ pass in {$log['pass']} quick inet6 proto ipv6-icmp from ff02::/16 to fe80::/10 i pass in {$log['pass']} quick inet6 proto ipv6-icmp from fe80::/10 to ff02::/16 icmp6-type {128,133,134,135,136} tracker {$increment_tracker($tracker)} keep state # We use the mighty pf, we cannot be fooled. -block {$log['block']} quick inet proto { tcp, udp } from any port = 0 to any tracker {$increment_tracker($tracker)} -block {$log['block']} quick inet proto { tcp, udp } from any to any port = 0 tracker {$increment_tracker($tracker)} -block {$log['block']} quick inet6 proto { tcp, udp } from any port = 0 to any tracker {$increment_tracker($tracker)} -block {$log['block']} quick inet6 proto { tcp, udp } from any to any port = 0 tracker {$increment_tracker($tracker)} +block {$log['block']} quick inet proto { tcp, udp } from any port = 0 to any tracker {$increment_tracker($tracker)} label "Block traffic from port 0" +block {$log['block']} quick inet proto { tcp, udp } from any to any port = 0 tracker {$increment_tracker($tracker)} label "Block traffic to port 0" +block {$log['block']} quick inet6 proto { tcp, udp } from any port = 0 to any tracker {$increment_tracker($tracker)} label "Block traffic from port 0" +block {$log['block']} quick inet6 proto { tcp, udp } from any to any port = 0 tracker {$increment_tracker($tracker)} label "Block traffic to port 0" # Snort package block {$log['block']} quick from <snort2c>to any tracker {$increment_tracker($tracker)} label "Block snort2c hosts"</snort2c>
-
Not quite sure i want to do that yet but will just know that this particular rule number relates to the default rules and not worry about it anymore.
Thanks for all your help.
Regards
Rob
-
It's been merged to 2.2.4.
-
Question slightly OT: Is it good practice NOT to log packages blocked by the default deny rule (Settings, first option under "Log Firewall Default Blocks"?
-
Hmmm… depends on how much noise you like, or what you policies are, or whatever. Wouldn't say there's any "best practice" here.
-
Im still trying to work out the best settings since I've only been using pfsense a few months so I've left logging on most things so i can see whats going on unless i really really don't want to know about something.