Puzzled by log file entries

Started by passeri, October 29, 2025, 01:45:31 AM

Previous topic - Next topic
I had an emerging problem where my mail server ceased to be able to access or be found outside its sub-net. I found that crowdsec was marked as blocking those messages so switched it off after which normal service was restored. Q-Feeds is still running on the WAN side. My public IP is not listed as an IOC in TIP.

In the course of this, I looked at the firewall log to find these (sample, abbreviated, unmatched, fake internal) entries, all TCP:

Source: 10.68.166.221:443
Dest: 177.36.61.165:42577
Action: block
Label: Block access to private nets

Source: 177.36.56.101:14851
Dest: 10.68.166.221:443
Action: pass
Label: let out anything from firewall

Should not the first be a pass and the second a block?
The 177.x.x.x addresses are not found in TIP IOC. Nor are they found by dig -x so it is understandable that they should be blocked, except it then seems the messaging is wrong.

Has something inverted here, or have I misunderstood it? I have made no changes to my firewall rules in ages other than adding the WAN floating rule for Q-Feeds.
Deciso DEC697

There could be a couple of things going on with the first. UI matching of rules with log entries can get confused when you modify the ruleset - a (rather annoying, but) functionally cosmetic issue, difficult to resolve with pf. Another possibility is the exact reason for a block may not be obvious, although I would expect session issues to hit the default block rule.

For the second, the automatic outbound pass rule will pass anything (not blocked by an inbound rule). I don't have enough information on your ruleset to determine if that is an expected behavior.

Or they could be something else, of course.