Messages

Better update the subject line too!

Others may be discouraged to update reading the subject alone.

I use the following lists to block malware IPs between all my firewall networks:

https://feodotracker.abuse.ch/downloads/ipblocklist.txt
https://rules.emergingthreats.net/blockrules/compromised-ips.txt

And this to block malware IPs as Source or Destination on my WAN interface only (as it contains private networks):
https://iplists.firehol.org/files/firehol_level1.netset

Again and again, those lists contain regular IPs that should not be blocked.
Therefor, I added whitelisting rules ... but those should of course not allow anything from or to the whitelisted IPs!

Instead, I removed Quick from the both the (Floating) whitelisting and blocking rules, set the tag "blocked" on the blocking rules and "whitelisted" on the whitelisting rules.

The whitelisting rules come after the blocking rules, to that the tag get's changed from "blocked" to "whitelisted" - and then I have a final Floating rule that just blocks all traffic that has the "blocked" tag.

Is this the right way to handle this?

I first thought that inverting the tag "whitelisted" with "!whitelisted" would be the easiest way, but that syntax does not seem to be supported and I had no idea how to correctly implement whitelisting in other ways.

I have another example for the same underlying problem with wrong logging:

Here, a package gets apparently blocked by the rule "Block FRITZ to all non-routable".
This is clearly wrong, as it is a package from an IP to the broadcast address in the same network, which is allowed in an earlier rule!

Instead this package gets blocked by a Floating rule "NL Block Ports", where ports 135 to 139 are blocked!
But this rule is non-Quick!

This is the same wrong behavior we saw above!

A non-Quick rule does not get logged anymore, instead some other rule will be logged.

I implemented a new test case:

1) The Pass rule, non-logging
2) The logging Block rule, with Source "! FRITZ net"
3) Then again the same rule, with Source "any"
4) And just to check if that plays a role, a copy of this last rule - to check how it will be logged

I disabled logging for the default rule now.

Here is the screenshot:

I tested with this and finally saw those packages again, blocked by my "Block FRITZ all other".
To complete the test, I then disabled "Quick" for "Block FRITZ all other" and now I see the packaged logged with "Block FRITZ all other COPY" instead, which is a copy and just comes later.

So it is as I suspected, the non-Quick default deny / state violation rule will not be hit and logged, when there is a Quick-Rule somewhen later.
For me, this is unsuspected in that the Quick rule seems to apply state as the reason for blocking, which should instead be blocked by the default rule.

So, only when I delete both block rules, I can see the default rule login again.
I would rather prefer to have the default rule as Quick, so that it can directly apply!

But I now understand logging much better, thank you!

P.S. Somehow I see no way to attach the screenshots, will try later.

I implemented a new test case:

1) The Pass rule, non-logging
2) The logging Block rule, with Source "! FRITZ net"
3) Then again the same rule, with Source "any"
4) And just to check if that plays a role, a copy of this last rule - to check how it will be logged

I disabled logging for the default rule now.

Here is the screenshot:

Why do you need a block rule before the default block in the first place?

I thought that this is obvious:

I want to log any such package, if it ever occurs.

[not]

Let's try again:

I have a Pass rule that allows Source "FRITZ net" to any destination for the FRITZ interface.
This Pass rules did not apply because of state, as it seems - from the information seen with the "i" button. I see only "PA" or "A" TCP flags set.

The "Default deny / State violation" rule comes first, but it has "Quick" not set, so that other rules are applied as well.

My Block rule was meant to catch IPs that are not from FRITZ net, as it has Source "any", not Source "FRITZ net" like the Pass rules - to any destination.
So it should normally only apply when a spoofed IP tries to reach anything!

Here is where you go wrong: Source "any" catches everything, which includes FRITZ net. And why shouldn't it? It is a catch-all rule that is always being applied before the default block rule, just because it matches anything. You could have noticed this long ago by the fact that the log entry tells you it is because of this very rule matching (and blocking): Look at the log entries, the label says "Block Fritz all other", which is exactly your second rule.

If you wanted it to match only traffic that is not from FRITZ net, you would need to change the source to "!FRITZ net", not "any" (including FRITZ net). If you do that, then the default block rule would be applied.

Source "any" is used in the Block rule, not in the Pass rule.

But I know understood, that you are telling me that the Block rule catches packages with state problems too and will do so instead of the default rule?

That is a valid argument!
I will change the Block rule to Source "! FRITZ net" and enable logging for both block rules!

Many thank!

Whatever, regular default-deny /state-violation packages should be logged for this rule and not with some other, user-added rule!
That should be clear.

No, that's not how it works. If some rule you define has already matched a packet and acted upon it, that packet will not reach the default block, whether logging is enabled or not. I vaguely recall there being match type rules which allowed you to act on a packet but it still traverse the rest of the interface rules. But don't see that in current opnsense.

I never said something like you seem to assume!
You are mixing up my tests, where I enabled logging for the default block rule - in this case, the right rule will be logged!

[explicitely enabled logging]

So then, the only misunderstanding is that you seem to know why your allow rule does not fire (namely because of state violations - if you search this forum for that you will find many examples of people having created split routing, as I said). And yes, you have shown the log entries, but not the rule details, AFAICS.

Apart from that, the logs you showed last are clearly from the second, blocking rule, for which you have explicitely  enabled logging as shown in your first post, so what is the problem?

I can see still just one: Your packets are not being allowed for whatever cause (could be split routes, as indicated by invalid states), thus, this rule does not match and your second rule fires and gets logged, which is to be expected.

You seem to imply a problem with OpnSense or its logging and I do not see this, please explain how you come to your conclusion?

It is obvious that I was not able to bring over my point or my reasoning.

Let's try again:

I have a Pass rule that allows Source "FRITZ net" to any destination for the FRITZ interface.
This Pass rules did not apply because of state, as it seems - from the information seen with the "i" button. I see only "PA" or "A" TCP flags set.

The "Default deny / State violation" rule comes first, but it has "Quick" not set, so that other rules are applied as well.

My Block rule was meant to catch IPs that are not from FRITZ net, as it has Source "any", not Source "FRITZ net" like the Pass rules - to any destination.
So it should normally only apply when a spoofed IP tries to reach anything!

But we clearly see that is traffic from FRITZ net to some Internet IP - something that normally should have been allowed by the Pass rules already!
My Block rule should NOT apply here, as the source IP is clearly from FRITZ net!

What is finally blocking the package is the "Default deny / State violation" rules, from all what I can see.

Yet, the package get's blocked and will be logged with my Block rule "Block FRITZ all other".

And this is wrong!

It should be logged with the "Default deny / State violation" rules because this is the reason it got blocked!
But it seems that logging will not be done with the actual rule when this rule has "Quick" missing.

This is at least my interpretation.

To formulate this in a different way: For me it seems that OPNsense logs with the last rule that blocks, when the "real" blocking rule has "Quick" not set and logging disabled.
It kind of forget's the real reason for the block.

And yes, that feels very much like a bug!
The wrong rule will be logged.

Was that more clear?

IDK what you expect to see in your logs:

• You have a rule that does not fire (for whatever reason, you did not show the rule details and the list view does not give any hint as to why).
• You have a rule that seems general enough to fit anything else with logging enabled.
• You see packets logged for that second rule.

You can change the default block logging any way you want. Because this default rule would only be applied after all other rules, it is never being touched in this situation.

On the surface, I can see nothing that does not work as designed or configured by you. The only open question is why your first allow rule does not fire. And as said multiple times, we cannot tell because you did not show it in full.

The reason can be anything. The most probable cause is split routing, such that the TCP state matching does not work. This could happen if you WiFi AP on the Fritzbox is active or if you otherwise created a network loop.

No, you didn't get the current situation:

It seems clear that those packages get blocked because of state violations. I just assumed that my pass rule should have allowed them, but the "i" revealed the details.

But still they get logged with my rule, when logging is enabled.
This is wrong and seems to be a bug.

And I believe that the logs I showed are clear in that - at least I don't know to else to deliver.
Any wishes?

I just saw them again, default blocks has logging disabled.

The question is, why those packages are logged with the wrong rule!
I disabled the rule and enabled logging of default blocks - and bamm, those packages are logged as "default deny / state violation", which is right!
But when I instead have my last rule logging, it will be logged with this!

So, with default drop logging enabled and your own rule disabled, you see dropped packets logged under the default rule description.
Then, with default logging disabled and your drop rule above enabled, you see packets dropped and logged under your rule's description (however only for the interface concerned).

Yes.

What's more, if you have both your rule, and the default logging enabled, dropped packets (on that interface) will be dropped and logged by your rule alone. Those same packets will not encounter the default drop rule.
If that's what you're seeing, and its not totally clear TBH, that is what I would expect.
Regarding packets logged under the wrong rule, I believe this can appear to happen and I may have misunderstood your question.

I didn't test this and I cannot force such packages, I just noticed them and wondered.

Whatever, regular default-deny /state-violation packages should be logged for this rule and not with some other, user-added rule!
That should be clear.

We have seen no evidence that you have understood how those rules work. What ip-range is fritz-net.

Not sure what to not understand here.

The FRITZ net is a FritzBox as access point for WiFi devices and has 192.168.1.0/24

As it seems, out-of-state packages get logged with my last rule, if logging is enabled, even as this rule should not apply (but the default deny).

That should not be the case.

I found this, which is a bit similar:

https://forum.opnsense.org/index.php?topic=20219.0

When those are out-of-sync packages, the question remains why they get logged under this rule, which seems to be wrong.

Post 4 explains how packet filter and states work and gives a likely cause for what you are seeing. In your example above, I imagine you will NOT find any blocked packets with `tcpflags==S`.

The question is, why those packages are logged with the wrong rule!
I disabled the rule and enabled logging of default blocks - and bamm, those packages are logged as "default deny / state violation", which is right!
But when I instead have my last rule logging, it will be logged with this!
And that is simply wrong.

Seems to be a problem with OPNsense logging.

I found this, which is a bit similar:

https://forum.opnsense.org/index.php?topic=20219.0

When those are out-of-sync packages, the question remains why they get logged under this rule, which seems to be wrong.