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?
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.
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.
Quote from: patient0 on June 21, 2025, 06:27:39 AMBtw: 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.
@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.
Quote from: keeka on June 21, 2025, 07:00:19 AMThe 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.
Quote from: patient0 on June 21, 2025, 06:27:39 AMBtw: 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.
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.
Quote from: senseOPN on June 21, 2025, 11:00:12 AMI 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 (https://forum.opnsense.org/index.php?msg=93687) 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`.
Quote from: keeka on June 21, 2025, 08:30:23 PMQuote from: senseOPN on June 21, 2025, 11:00:12 AMI 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 (https://forum.opnsense.org/index.php?msg=93687) 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.
We have seen no evidence that you have understood how those rules work. What ip-range is fritz-net.
Quote from: senseOPN on June 22, 2025, 11:52:52 AMThe 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.
Quote from: Bob.Dig on June 22, 2025, 01:40:13 PMWe 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.
Quote from: keeka on June 22, 2025, 03:47:58 PMQuote from: senseOPN on June 22, 2025, 11:52:52 AMThe 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.
Quote from: keeka on June 22, 2025, 03:47:58 PMWhat'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.
I just saw them again, default blocks has logging disabled.
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.
Quote from: meyergru on June 22, 2025, 05:55:30 PMIDK 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?
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?
Quote from: senseOPN on June 22, 2025, 05:16:54 PMWhatever, 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.
Quote from: meyergru on June 22, 2025, 06:21:27 PMSo 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?
Quote from: keeka on June 22, 2025, 07:00:44 PMQuote from: senseOPN on June 22, 2025, 05:16:54 PMWhatever, 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!
Quote from: senseOPN on June 22, 2025, 10:55:03 PMLet'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.
Quote from: meyergru on June 22, 2025, 11:06:17 PMQuote from: senseOPN on June 22, 2025, 10:55:03 PMLet'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!
Why do you need a block rule before the default block in the first place?
Quote from: Patrick M. Hausen on June 23, 2025, 07:20:58 PMWhy 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.
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:
Quote from: senseOPN on June 23, 2025, 08:57:14 PMI 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 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.