Can this combined rule be separated into two, one for a state validation failure, and a separate one for Default Deny?
Rationale: When I rebuilt our Firewall over the Christmas break, there were a number of anomalies as I tried to get rules working correctly. It was a significant impediment not knowing whether traffic was passed or blocked because my rules were incorrect, or simply because I had cleared states to ensure that the rules would be applied after changing them.
Even now, with everything working, I see many periodic "Default deny / state violation rule" events logged continuously from sources to targets that should be passed, and appear to be working just fine. So I assume that for some reason the state was invalid... but I don't know.
I assume without confidence, because, well, what else could it be? And that's my point; rules are confusing enough without having ambiguity in the default rules.
I always define my own default block rules, per-interface. Anything that triggers the automatic default block then is an anomaly, as you've seen - something I hadn't considered or a quirk of the stack. Having your own block rules just makes the quirks easier to spot.
Example: Blocking multicast on a bridge results in 7 log messages per packet. Do I win the wacky log prize?
Quote from: L. Cornelius Dol on February 07, 2025, 06:26:11 PMCan this combined rule be separated into two, one for a state validation failure, and a separate one for Default Deny?
I've wondered about that one too.
I suspect the existence of state (and traffic being allowed based on its presence) implies that it's generally not possible.
A packet might have been allowed if the state still existed (or was just different).
For example, is some reply packet really unsolicited or merely corresponding to expired state?
But I'm far from an expert on that subject...
Quote from: L. Cornelius Dol on February 07, 2025, 06:26:11 PM...
Even now, with everything working, I see many periodic "Default deny / state violation rule" events logged continuously from sources to targets that should be passed, and appear to be working just fine. So I assume that for some reason the state was invalid... but I don't know.
I assume without confidence, because, well, what else could it be? And that's my point; rules are confusing enough without having ambiguity in the default rules.
In my experience, that typically happens with state that expired because the connection went idle for too long (versus being explicitly closed).
The FW will drop connections at some point.
The client might retry once or twice but will typically end up re-establishing a new connection completely transparently.
Such resilience has to be built into apps...