Incorrect rule labels assigned in firewall live view

[glasi]

Hi all!

I am currently running OPNsense 19.1.6-amd64 and today I've experienced some hiccups within the firewall module.

The system assigned incorrect rule labels to the logged packets in the firewall live view. E. g.: Logged packets have been flagged with labels anti-lockout rule or allow access to DHCP server on the pppoe interface while no such rules have been set up on the pppoe interface in the firewall module.

After restart of the packet filter the issue was gone.

As far as I can tell firewall rules nonetheless have been applied correctly. I hope this is just a buggy firewall live view.

Please let me know which internal log files to keep track of if the same problem reoccurs.

[glasi]

The problem persists. The system still assigns incorrect rule labels to the logged packets in the firewall live view.

Again, the restart of the packet filter seems to solve the issue (temporarily).

[hbc]

I can confirm this problem. I run tcpdump to verify access. I saw 3-way handshake and traffic passing, while 'live view' told me that traffic has been blocked.

I also tried:

Code: [Select]

#  tcpdump -n -e -ttt -i pflog0
Shows also blocked traffic while it passes. It is a bit confusing, because you never can sure whether allow traffic is really allow or a rule has been forgotten. But seems to be a pf/pflog problem.

[DerShorty]

Hi,

just found this Topic by Google because I was experiencing this issue too.

I hope this is just a buggy firewall live view.

In Network-Security there is no space for hope. Also a simple 'oops' is too much. - I will move over to pfsense now. It is anyway more well documented for my opinion, plus I have the trust that its working correctly.
This issue with wrong labeled firewall rule, isn't the only strange matter I've seen so far. There was many more, for example NATing: I had to put in wrong Alias to make it work. Another thing is to check suspicios option in settings when planning access on WAN.
 
Hows telling me that this wrong labeled firewall logs (and others) do not impact or interference other functions? May it is exploitable due to this? How knows? - I don't. And the Team doesn't look to make a statement to this topic, since it persist for nearly a month now.
 
Im no technician, but simple User.
And a simple User just wants working software. Thats it.

[hbc]

The question is whether pfsense will not have the same problem. Because I think it is a pf thing.

But the problem is really annoying. I just see a bench of 'blocked by default rule' entries in live log for access to my local squid instance, while tcpdump shows that the download via proxy works perfect.

For me every block message in live log that should not be blocked because of a permit rule, has to be manually checked via tcpdump or telnet. :-(

[Northguy]

Im no technician, but simple User.
And a simple User just wants working software. Thats it.

This is a user forum for a community based open source firewall solution. This means that people are spending their free time to improve the software YOU use. Personally I find your 1st post disregarding the effort that many put in improving the codebase. Developers don't jump up to solve and search issues on your demand. You either accept that a bug might be present and contribute to improvements by logging a properly documented bug report on the GitHub, you pay for support from Deciso, or you buy a commercially available solution.

[franco]

Try the dev version: it has labels and rule reference info synced against automatic rules as well and will display them in the GUI and packets, bytes, states and evaluations for each rule.

Try GitHub: to report issues to the developers, or better yet ask questions why it may not work as you expect. Sometimes it works as intended. Sometimes it works as good as it can be, because...

We use a runtime approach to rules where firewall logs are only accurate with label information when they are displayed along with the ruleset which is in sync with the reporting data. If new rules are added the old "index" shifts and you may see the wrong rules.

pfSense uses a non-FreeBSD "tracker" subset for pf(4) so that their rules are always labelled correctly (I would expect that to be the case for the effort spent). We try not to add more to pf(4) so we build around the ability to identify rules in pf(4) output.

It cannot be a security issue, the only consumer of the label data is you as it was added for your convenience in the first place.


Cheers,
Franco

[glasi]

[...]

We use a runtime approach to rules where firewall logs are only accurate with label information when they are displayed along with the ruleset which is in sync with the reporting data. If new rules are added the old "index" shifts and you may see the wrong rules.

[...]

Hello Franco,

thanks for explanations.

I guess that in my case the old index most likely shifts because of dynamic aliases.

From my point of view a reindexation should take place after e.g. an url table alias has been updated. Are changes already planned in this respect?? Or should I open a GitHub ticket?

[AdSchellevis]

It would be better if the pf log output contained its label, which is a calculated hash in the dev version. Reindexing the rules won't really help, since you would always need to store exact time slices for every change in the ruleset.

We don't have any changes planned in this regards, you can always open a ticket for it, but realistically it would probably only make sense if someone wants to do the work for it.

Best regards,

Ad

[franco]

Someone actually did the right thing by raising a bug report with a reproducible suspicion rather than coming off as whatever this was here... and the suspicion is pretty reasonable: you use a different firewall rule optimisation setting and on top of it there are rules which get removed by the optimisation because some of them don't do anything so they get removed and shift the label index in the wrong way.

https://forum.opnsense.org/index.php?topic=13308.0

It's pretty easy to find bugs if you stop your judgement and try to find out why so to help get to the bottom of issues, but I fear some people have not learned this despite constant reminders in this forum that this is *the only way* forward.

https://github.com/opnsense/core/commit/1d1ce841ffe9


Cheers,
Franco

[abulafia]

Apologies for hijacking this thread, but I experience similar issues on 21.1:

The "live view" shows wrong labels, e.g. for my "plex forward rule" (port forward anything to :32400 to my internal Plex server) it shows my "Block_IP_INGRESS" IP block rule and vice versa.

I have done no changes to "firewall optimization".

I do have changed my rules and deleted some; I will need to check whether this disappears after a reboot (but I think not as it keeps bugging me for the past few weeks).