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

[senseOPN]

I have a rule to allow traffic from Source "FRITZ net" on the FRITZ interface to access any destination.
After this rule, I have a rule "Block FRITZ all other" that blocks all remaining traffic to any destination, with Source any, on this interface.

Still I see blocked packages that should have been allowed by the pass rule already!

192.168.1.102 and .104 are iPads in the FRITZ net.

Something seems broken, or?

[patient0]

What does it say when you click the 'i' icon? Often if a allow-all rules is blocked the it's connections with TCP options, which are blocked by default. Check your rule, under 'Advanced features' -> 'allow options'.

Btw: you 3rd rule, redirect NTP to local is an odd rule: it will never be executed, it's already included in the first rule.

[keeka]

The blocks may be TCP state violations. AIUI when you create tcp allow rules, with default allow options, packets other than syn will be blocked if there is no matching state.

Btw: you 3rd rule, redirect NTP to local is an odd rule: it will never be executed, it's already included in the first rule.

Whilst opnsense can create related firewall rules for your NAT rules, you may still have to reorder the resulting filter rules. The resulting rule may even be redundant, as in this case. You can then either ignore it or disable the filter rule in the associated NAT rule.

[senseOPN]

@patient0 when trying to reply directly to you, I saw no way to attach the image.

I have no idea how to interpret this 😅

The advanced options are at default, with Keep State.

[senseOPN]

The blocks may be TCP state violations. AIUI when you create tcp allow rules, with default allow options, packets other than syn will be blocked if there is no matching state.

Btw: you 3rd rule, redirect NTP to local is an odd rule: it will never be executed, it's already included in the first rule.

Whilst opnsense can create related firewall rules for your NAT rules, you may still have to reorder the resulting filter rules. The resulting rule may even be redundant, as in this case. You can then either ignore it or disable the filter rule in the associated NAT rule.

Yes, I noticed this as well and was not sure how to handle this.
Probably it would be best to remove this rule when the NAT redirection still works without it.

[senseOPN]

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.

[keeka]

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`.

[senseOPN]

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.

[Bob.Dig]

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

[keeka]

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).
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.

[senseOPN]

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.

[senseOPN]

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.

[senseOPN]

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

[meyergru]

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.

[senseOPN]

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?