pfBlockerNG-devel is blocking traffic from an unmonitored NIC

[deleted]

Hello everyone,

I'm having an issue where pfBlockerNG-devel (ver. 3.2.16) is blocking traffic on a network interface that I specifically don't want to monitor.

How can I make sure that no monitoring is taking place at all? Or should I file a bug report instead?

[SteveITS]

@deleted On pfBlockerNG > IP page change your "Outbound Firewall Rules" interface(s).

[deleted]

@SteveITS

There, I selected the NICs I want to monitor.
However, the one in question is still not selected.

That's the only place to configure it, right?
Then I guess I'll have to file a bug report.

[SteveITS]

@deleted So pfSense has the pfB firewall rules on this other interface? You ran an update in pfBlocker since changing that?

[deleted]

@SteveITS

Yes, exactly. On an interface that has never been monitored and never will be.

I can confirm that pfBlocker is blocking it, since it works after turning it off.
The rule has a name that is unknown:
@11 block drop in log inet all label "descr=Default deny rule IPv4" label "tags=ruleset:7bf27b300e6a9fde" ridentifier 1000000113

[SteveITS]

@deleted The default deny would be the rule reached if a packet wasn't allowed. I would have no idea how "how you got there" is related to pfBlocker allow or deny rules above it.

[tinfoilmatt]

ITT: confrontational confusion.

[deleted]

“I didn't do anything!”

Seriously, I have no idea how this happened.
It's a simple configuration, and since the NIC has never been used, it confuses me even more.

How can I open a bug ticket?

[SteveITS]

@deleted Rereading, it sounds like you’re getting blocks on an interface you’re not using. Can you show a screenshot of the firewall log?

Is this interface connected?

Any chance the IP on this interface is 10.10.10.1? That’s the traditional virtual IP for DNSBL (which you haven’t mentioned using). Though that can be changed.

[Gertjan]

When traffic hits this rule :

@deleted said in pfBlockerNG-devel is blocking traffic from an unmonitored NIC:

@11 block drop in log inet all label "descr=Default deny rule IPv4" label "tags=ruleset:7bf27b300e6a9fde" ridentifier 1000000113

then this tells me that the firewall rule for that interface looks like like this :

and in that case the 'default' (hidden rule, with ID 1000000113) kicks in and blocks everything (except local DHCP traffic).
This isn't a pfBlocker firewall (floating or not) rule btw.

If there are 'admin created' firewall rules for this interface, put this one :

at the top of the list and everything = all traffic will pass, no matter what the subsequent rules (pfBlocker or not) are.

[tinfoilmatt]

Great description, but fix that typo!

Many years were needed to find this rule.

(I'm a closet admirer of your English proficiency by the way.)

[Gertjan]

@tinfoilmatt
Corrected. Thanks.

To make the firewall rule empty as an example, I had to delete this single rule, thus blocking devices on that network.
I recreated (fast) the rule afterwards, and had the Comment in the Ctrl-C/V buffer, which I deleted as I copied the image into the post.
It's just a silly comment btw.

[deleted]

Thank's for our replies.

@SteveITS
Yes, the interface is connected. A PC is connected directly via a cable, and it has a static IP address.

The setup is simple; without any further steps, traffic goes out to the internet. No VPN or anything else runs through the Sense.
With very few exceptions, DHCP is never enabled on any NIC. And if it is, it’s not on the one in question.

@Gertjan
I have exactly the same rule active as in your second image.
It’s also the only one, and I can see from the stats that it’s being used.

I can confirm that the relevant controller is not selected in the settings under the IP tab and in the DNSBL section.

Furthermore, I don't use a network in the 10. ...
10.10.10.1 // 127.1.7.7 are reserved by default for the pfBlocker.

[SteveITS]

@deleted Possibly https://docs.netgate.com/pfsense/en/latest/troubleshooting/log-filter-blocked.html#out-of-state-web-server-packets ? We normally turn off logging for the default rules because it saves a lot of log noise and disk writes, and then turn it on if/when necessary.

We've established a pfBlocker rule isn't blocking it because the packets are hitting the default deny rule. Left unclear is why enabling or disabling pfBlocker is reportedly relevant. It's not adding an allow rule on that interface is it?

[Gertjan]

@deleted

Console, SSH :

ifconfig | grep '192.168.9'

[deleted]

@SteveITS
What exactly do you mean—setting the TCP flags or disabling the “Default firewall ‘block’ rules” option under Logging Preferences?

But yeah, you're right, that's actually nonsense.

In principle though it can't be related to that.
I definitely have blocks from that NIC in the pfBlocker log.

@Gertjan
inet 192.168.9.1 netmask 0xfffffff8 broadcast 192.168.9.7

[Gertjan]

@deleted said in pfBlockerNG-devel is blocking traffic from an unmonitored NIC:

inet 192.168.9.1 netmask 0xfffffff8 broadcast 192.168.9.7

Humm, I was hoping to see :
inet 192.168.9.1 netmask 0xfffffff8 broadcast 192.168.9.255 - as that tells me that the network is a /24.

[SteveITS]

@deleted said in pfBlockerNG-devel is blocking traffic from an unmonitored NIC:

blocks from that NIC in the pfBlocker log

Please show that log?

[deleted]

@SteveITS

Sorry for the delay.

This is from just now, after a reboot.
And based on the settings described, this shouldn't be happening:

How can I report this more accurately? A screenshot alone is still a bit vague.

However, I can confirm that I've been noticing this for at least one patch, though I initially thought it was a configuration error on my part.

[SteveITS]

@deleted well that’s a DNSBL entry not a firewall log entry. If you don’t want it blocked then don’t enable whatever DNSBL list that is.