Feature request: Option to enable logging for all firewall rules at once

[JasMan78]

When the firewall ruleset becomes bigger and bigger, and you've found out that an client has access to something that it shouldn't have, it's sometimes difficult to find the rule which allowes the traffic.

In this case it would be great to have an switch, which enables the logging for all rules at once, to identify the rule which allowes the traffic.

[AdSchellevis]

closed with #3605 thanks to @johnaheadley, "select all" didn't make it (see PR for discussion), but per item toggle is way easier now.

[Nadahar]

I'd say that an "log all" option would be very helpful when trying to debug when something doesn't behave like you want it to. Easier toggling of the logging doesn't really help, you don't want to (at least I don't) "disturb" the normal configuration of what to log and not by turning on a lot of rules you normally don't want logged. You just want to see everything while debugging the issue, so that the "problem" doesn't elude you because some rule you didn't think of come into play.

[fichtner]

It's not 2019 anymore and we had a couple of people flooding their logs. From my side that is still a 'no'. :)

[Nadahar]

I see this as just as relevant in 2023. Is there another way to "see all that's happening" then? Otherwise I see no other solution than to find pen and paper, write down the current logging status of all the rules, enable them all - and then undo all that from the "paper backup" once done with debugging. It's not a very tempting solution.

[fichtner]

"What" is happening is easy to debug with selective rules. The problem isn't the world. It's a sever not working. NAT not responding, etc.

[AdSchellevis]

use the packet capture to follow the flow and read the ruleset based on what you're seeing there, always works

[Nadahar]

@AdSchellevis I've tried to use the packet capture, but I'm a bit confused as to how that works. I find the packets coming in on one interface, but they never leave on the other. So, I assume that some rule, that isn't being logged, interferes. Maybe that's not the case, but it sure would be helpful to verify.

Is it correct to assume that the packet capture only captures what happens "outside" the firewall (before on incoming, after on outgoing)?

[AdSchellevis]

if you're capturing all interfaces, traffic flows in, but never out, a filter rule is one of the most common issues, which you can then easily validate as Franco suggested with selective rules. you're seeking for tools either nog very useful or already available. best use our forum for discussions.

[Nadahar]

I didn't mean to use this as a support forum - I merely tried to use my example as a situation where this could be useful.

The reason for my question was that it was using the packet capture that led me to the conclusion that I need for figure out exactly what goes on with filtering/NAT/routing. So, I wondered if I had misunderstood somehow, and that I could understand more of what happens from the packet capture itself.

For context: I am trying to migrate an installation from pfSense to OPNsense. This works with pfSense - which leaves two possibilities as I see it: I've either overlooked something when trying to copy the setup, or OPNsense behaves differently. I'd like to figure out which it is and why. So, it's not as simple as some straight forward rule that blocks the traffic. I've already turned on logging on every rule I think is remotely related, but I see no trace of these in the firewall log. Which is why I feel it's time to see everything that happens to try to figure out what is happening.

I get that you don't want this, so I won't go on about it. I just still think it would be very useful for debugging "difficult situations". I do understand the risk of huge logs, but frankly that's possible to make without such a function too. And you could put whatever warnings and other "protection" you'd like on it, to minimize the risk. So, I understand it like what you're saying is that you just don't see the need.

For info: I enabled logging for all rules "manually", after which it took me less than 10 minutes to pin down the problem. It was a Gateway setting (under Advanced features) that hadn't made it in the migration.