PF Viewing pflog rule w/ label or tag in tcpdump?

codeedog · Mar 4, 2025

I've been working my pf.conf rules and adding labels and tags. Perhaps I've been spellbound, but I assumed pflog would contain this information and tcpdump would display it. Here's an old mailing list entry about a label patch for tcpdump.

Is there some magic for viewing at least a label attached to a log entry?

See below for the pf rule, tcpdump options and output. BTW, despite "if_src_gate" being in the label and the log, the log entry was generated from the block rule's position inside an anchor named "if_src_gate". Perhaps, with a liberal use of anchors, having the label in the log is not critical. Still, I'd like to know if it's possible for other debugging purposes.

Thank you.

Code:

# /etc/pf.conf: rule 7.8/0 is
#   block quick log tagged NOTAG label "if_src_gate $if"

# tcpdump -n -e -tttt -vvv -r /var/log/pflog 

2025-03-04 13:37:52.529874 rule 7.if_src_gate.8/0(match): block in on e0a_dnsj: (tos 0x0, ttl 64, id 36183, offset 0, flags [none], proto UDP (17), length 69)
    10.10.5.7.13955 > 1.1.1.1.53: 33438+ [|domain]

SirDice · Mar 5, 2025

codeedog said:
Perhaps I've been spellbound, but I assumed pflog would contain this information and tcpdump would display it.

Check pflog(4):

Code:

     Each packet retrieved on this interface has a header associated with it
     of length PFLOG_HDRLEN.  This header documents the address family,
     interface name, rule number, reason, action, and direction of the packet
     that was logged.  This structure, defined in ⟨net/if_pflog.h⟩ looks like

Here's an old mailing list entry about a label patch for tcpdump.

Patch was never applied to the source tree.

If you look at net/if_pflog.h you'll see the structure doesn't contain a reference to the label. Thus this information simply isn't logged.

Code:

struct pfloghdr {
        u_int8_t        length;
        sa_family_t     af;
        u_int8_t        action;
        u_int8_t        reason;
        char            ifname[IFNAMSIZ];
        char            ruleset[PFLOG_RULESET_NAME_SIZE];
        u_int32_t       rulenr;
        u_int32_t       subrulenr;
        uid_t           uid;
        pid_t           pid;
        uid_t           rule_uid;
        pid_t           rule_pid;
        u_int8_t        dir;
        u_int8_t        pad[3];
        u_int32_t       ridentifier;
        u_int8_t        reserve;        /* Appease broken software like Wireshark. */
        u_int8_t        pad2[3];
};

aafbsd · Mar 11, 2025

codeedog said:
I've been working my pf.conf rules and adding labels and tags. Perhaps I've been spellbound, but I assumed pflog would contain this information and tcpdump would display it. Here's an old mailing list entry about a label patch for tcpdump.

I have a local patch for 14-STABLE which adds the first label of a rule to the tcpdump output.
If interested I can submit a PR or create a review request on Phabricator.

Kristof Provost · Mar 22, 2025

pfsense uses the 'ridentifier' field to link rules (even old now removed rules) to pflog output. That's probably the way to go to achieve what you want.

Adding the label presumably changes struct pfloghdr, which is going to break existing applications, so that's almost certainly a non-starter. (I say 'almost', because I have vague memories of a length or a rounded length being involved as well, but they're drowned out by the memory of how painful even just adding the ridentifier was. Do not underestimate how much extra work this involved beyond just making it work on your machine.)

aafbsd · Mar 22, 2025

Kristof Provost said:
Adding the label presumably changes struct pfloghdr, which is going to break existing applications, so that's almost certainly a non-starter. (I say 'almost', because I have vague memories of a length or a rounded length being involved as well, but they're drowned out by the memory of how painful even just adding the ridentifier was. Do not underestimate how much extra work this involved beyond just making it work on your machine.)

Yes, I saw several commits of you regarding this. I got away with

Code:

--- sys/net/if_pflog.h.ORI      2023-12-27 17:50:09.000000000 +0100
+++ sys/net/if_pflog.h  2025-03-11 17:44:52.000000000 +0100
@@ -37,6 +37,12 @@
 
 #define        PFLOG_RULESET_NAME_SIZE 16
 
+#ifndef PF_RULE_LABEL_SIZE
+# define PF_RULE_LABEL_SIZE 64
+#elif PF_RULE_LABEL_SIZE != 64
+# error Adjust PF_RULE_LABEL_SIZE in if_pflog.h
+#endif
+
 struct pfloghdr {
        u_int8_t        length;
        sa_family_t     af;
@@ -44,6 +50,7 @@
        u_int8_t        reason;
        char            ifname[IFNAMSIZ];
        char            ruleset[PFLOG_RULESET_NAME_SIZE];
+       char            label[PF_RULE_LABEL_SIZE];
        u_int32_t       rulenr;
        u_int32_t       subrulenr;
        uid_t           uid;
--- sys/netpfil/pf/if_pflog.c.ORI       2024-07-21 08:29:43.000000000 +0200
+++ sys/netpfil/pf/if_pflog.c   2025-03-11 17:45:19.000000000 +0100
@@ -233,6 +233,8 @@
        hdr.action = rm->action;
        hdr.reason = reason;
        memcpy(hdr.ifname, kif->pfik_name, sizeof(hdr.ifname));
+       /* we copy only the first label */
+       memcpy(hdr.label, rm->label, PF_RULE_LABEL_SIZE);
 
        if (am == NULL) {
                hdr.rulenr = htonl(rm->nr);

on the kernel side and changed pflogd and tcpdump (including libpcap). I do not have other
"consumers" of struct pfloghdr...

Kristof Provost · Mar 22, 2025

Right, I figured that would be the approach. It's fine for your own system, of course, but it's likely not upstreamable this way. I believe that if you only apply the kernel change (which is an expected use case, where we have a newer kernel than userspace) this will break things.

aafbsd · Mar 22, 2025

Kristof Provost said:
... if you only apply the kernel change (which is an expected use case, where we have a newer kernel than userspace) this will break things.

Yes, of course. But how does this differ from other kernel changes that change the ABI?
BTW, I played with ridentifier as well. But this is just a number and no text so I could
also have sticked with listing the rule numbers...

Kristof Provost · Mar 22, 2025

But how does this differ from other kernel changes that change the ABI?

It doesn't, but we usually try to avoid ABI breakage.

BTW, I played with ridentifier as well. But this is just a number and no text so I could
also have sticked with listing the rule numbers...

The intent is for the ridentifier to be persistent, so if you change the rules (e.g. inserting a 'block' at the start) the ridentifier would still point to logically the same rule, where the rule number would change. Of course that depends on whatever generates your rules file doing this correctly, because there's no enforcement of anything at all on ridentifier numbers.

aafbsd · Mar 22, 2025

Kristof Provost said:
It doesn't, but we usually try to avoid ABI breakage.

Sure, I only wanted to help the OP (and maybe find s.o. who says "this is s.th. which could go into -HEAD"

).

codeedog · Tuesday at 8:32 PM

aafbsd thank you for the offer to help. I got pulled away on some other bits and decided I'd come back to this when I had a moment. Digging through pfsense configurations, I noticed ridentifier used liberally and figured if they've tagged everything with an identifier, they've probably had a good reason for doing that and probably finesses the label issue. Label, if fully integrated, would be brilliant. My ruleset is small and stable enough that I can get away with rule numbers or ridentifier, if not.

I didn't want to try out your change until I had a block of time to dedicate to it. Given the above discussion between you and Kristof Provost , I hope you understand why I will pass.

Appreciate the assistance and reading this thread has been educational.

PF Viewing pflog rule w/ label or tag in tcpdump?

Administrator