Pass rules does not seem to work, but the following block rule does.

[meyergru]

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?

[keeka]

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.

[senseOPN]

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?

[senseOPN]

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!

[meyergru]

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.

And this is why everything after this happens just as designed.

IMHO: case closed as for why this logging occurs unless you tell us something we did not know and told you already.


Still, you have to find out why your "allowed" traffic does not come through in the first place, because normally, there should be no traffic that has wrong states.

[senseOPN]

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!

[Patrick M. Hausen]

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

[senseOPN]

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.

[senseOPN]

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:

[senseOPN]

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.

[senseOPN]

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.