pf uses a "last matching rule wins" strategy. You can circumvent this by either using the "quick" keyword or reorder your ruleset.
These blocking rules at the beginning of your ruleset can be overridden by later rules:
Code:
block drop in on ! lo inet6 from ::1 to any
block drop in on ! lo inet from 127.0.0.0/8 to any
block drop in inet6 from ::1 to any
block drop in on lo0 inet6 from fe80::1 to any
block drop in inet from 127.0.0.1 to any
block drop in on ! egress inet6 from 2001:470:cc33::/64 to any
block drop in on ! egress inet from 192.168.***.0/24 to any
block drop in on re0 inet6 from fe80::261c:4ff:fe08:8c05 to any
block drop in inet6 from 2001:470:cc33::3 to any
block drop in inet from 192.168.88.3 to any
A simple way to check whether any of these rules are preventing name lookup is to add the following macro:
Code:
LQ = "log quick"
block drop in $LQ on ! lo inet6 from ::1 to any
block drop in $LQ on ! lo inet from 127.0.0.0/8 to any
block drop in $LQ inet6 from ::1 to any
Repeat this for those other rules.
In a SSH session to your server run
tcpdump(8) on the
pflog0 interface.
Code:
# tcpdump -eni pflog0
Now run your
dig command and if one of these rules blocks something it will end up on
pflog0 and will be parsed and shown by
tcpdump(8).
An example on my firewall:
Quote:
|
01:52:12.595180 rule 33/(match) block in on vr0: 192.168.2.254 > 224.0.0.1: igmp query (DF) [ttl 1]
|
After debugging you can simple redefine the LQ macro to either "quick" or nothing "".
BTW Usually blocking internal loopback traffic is a bad idea. That is why "set skip on lo0" exists
