Inaccurate information on "Status / System / Logs /Firewall" page
-
On the firewall log page (see title), when you click on any 'X' icon to determine why it was blocked you get:
The rule that triggered this action is:
@9(1000000103) block drop in log inet all label "Default deny rule IPv4"
or
The rule that triggered this action is:
@5(1000000003) block drop in log quick inet6 all label "Block all IPv6"
I know for a fact that some of these blocks are from other rules I created and have confirmed by disabling them and the log going away.
Why does the pop-up not tell you the actual rule that blocked versus having this message for everything? It certainly makes figuring out why something was blocked harder. Is it a bug? A GUI oversight? Working as designed?
-
Without seeing your ruleset I can only make a guess: Are you putting your block rules in the correct order? Remember that rules are read from the top down, so if you have a block rule placed after the Default Deny rule the first rule that applies to the packet will be applied.
-
I may have misunderstood what bri189 was stating but it looked to me like we was saying that the traffic was passed after disabling the custom rule. So there was no default rule to block the traffic.
I was watching an old hangout (specifically the Jan. 2014 - Firewall and NAT) and I think that CMB mentioned that if you are adding "too many" rules, that they somehow fail to log correctly.
-
Some clarifications: yes, the rule is enabled but the blocking in the log shows the default message from the original post versus saying my custom rule caught it.
I think what is happening (and I need to do further testing) is that unless you check the box for 'Log this rule' you get the default message, if you have logging on for that rule, you get your custom rule in the reason it was blocked. That's my hunch at least for now based on some testing I did, will verify that and post results back as soon as I get a chance.
-
I was watching an old hangout (specifically the Jan. 2014 - Firewall and NAT) and I think that CMB mentioned that if you are adding "too many" rules, that they somehow fail to log correctly.
That dates back to prior to 2.2.x+ versions. In 2.1x and earlier, only the rule number in the running ruleset was used. If you added or removed rules, at least some of the rule numbers changed. There was no record kept of the prior rule numbers, so after adding or removing a rule, your logs wouldn't necessarily match up to your current ruleset.
In >=2.2.0, tracker IDs are used on the rules. Those remain static, so you always have the appropriate match. With the exception of if you delete a rule entirely, then the firewall log will tell you after the fact that it can't find a matching rule for logs generated by the deleted rule, since one no longer exists.
Long story short: OP's logs in question were definitely blocked by the default deny rule.
I think what is happening (and I need to do further testing) is that unless you check the box for 'Log this rule' you get the default message, if you have logging on for that rule, you get your custom rule in the reason it was blocked.
No, if you have a block rule without logging enabled, any traffic blocked by that rule won't show in the firewall log at all. Sounds like you're creating block rules that don't actually match the traffic you think it's supposed to match. Where you get logs with the default deny, that traffic was definitely blocked by the default deny.
-
So@cmb:
Sounds like you're creating block rules that don't actually match the traffic you think it's supposed to match. Where you get logs with the default deny, that traffic was definitely blocked by the default deny.
There you go this is most logical conclusion.
Why don't you post up your rules, and then the details of your log show what was blocked.
-
After further testing you are correct and I was receiving false positives earlier and am learning the importance of good rule organization and not being too granular or too course.
Thank you all for the guidance!
