PF See blocked packets

Guys,

Please accept my sincere apologies, a very simple question. I have PF firewall, I use ncspot but probably I'm still missing some firewall rules to make it work.

But in general, what's the most straightforward way how to use e.g. tcpdump(1) to see blocked IP packets, so one can figure out what rules are necessary. Or, is easier to use some logs directly coming from PF?

Thank you!
 
pflog(4):
Code:
EXAMPLES
     Create a pflog interface and monitor all packets logged on it:

           # ifconfig pflog create
           pflog1
           # ifconfig pflog1 up
           # tcpdump -n -e -ttt -i pflog1
pf.conf(5):
Code:
     log   In addition to the action specified, a log message is generated.
           Only the packet that establishes the state is logged, unless the no
           state option is specified.  The logged packets are sent to a
           pflog(4) interface, by default pflog0.  This interface is monitored
           by the pflogd(8) logging daemon, which dumps the logged packets to
           the file /var/log/pflog in pcap(3) binary format.

pflogd(8):
Code:
DESCRIPTION
     pflogd is a background daemon which reads packets logged by pf(4) to a
     pflog(4) interface, normally pflog0, and writes the packets to a logfile
     (normally /var/log/pflog) in tcpdump(1) binary format.  These logs can be
     reviewed later using the -r option of tcpdump(1), hopefully offline in
     case there are bugs in the packet parsing code of tcpdump(1).
 
You should make sure that your firewall ruleset includes the "log" keyword in each rule that you want to view. You should also default to drop until another later rule passes the traffic.

Code:
block drop log all
pass out log on egress inet from (egress) to any

Following this, you may then view your traffic with:
/sbin/tcpdump -lnettti pflog0
 
Is tcpdump on an interface before or after any firewalling?
I agree with above that make sure you have "log" on blocks, and tcpdump on the pflog interface to see.
 
Is tcpdump on an interface before or after any firewalling?
Before. Packets don't stop arriving on the interface if you block them. It just means that the packet isn't passed to the rest of the network stack.
 
Before. Packets don't stop arriving on the interface, even if you block them
That's what I thought, but it's been a while since looking at code in that area. So tcpdump on an interface, then tcpdump on pflog could show interesting differences.
 
So tcpdump on an interface, then tcpdump on pflog could show interesting differences.
Yes, plus some strategic log keywords on various rules. But I rarely look at pflog, I usually do a tcpdump(1) on the internal interface and a tcpdump(1) on the external interface. If things don't move from internal to external (or vice versa) you already know it's probably being blocked by the firewall.
 
  • Like
Reactions: mer
Code:
block drop log all
A word of warning. Keep in mind that every packet will hit this rule, even if you allow that specific packet later on in your ruleset. I usually don't want to see all the crap that's being sent to me, it's just a bunch of noise. I'm more interested in the connections that are allowed, so I generally log my pass rules, not the block rules.
 
Yes, plus some strategic log keywords on various rules. But I rarely look at pflog, I usually do a tcpdump(1) on the internal interface and a tcpdump(1) on the external interface. If things don't move from internal to external (or vice versa) you already know it's probably being blocked by the firewall.
Just curious, if one has only one interface configured, say, igb0, what stands for internal and external interface there?
 
Just curious, if one has only one interface configured, say, igb0, what stands for internal and external interface there?
Typically external interface refers to the wan-facing interface and internal refers to lan-facing (if its acting as a gateway for your network). With only one interface, its will likely just be wan-facing or external.
 
Back
Top