IPv4 connections (states) being incorrectly matched by IPv6 rule?

[luckman212]

I'm noticing a behavior that I can't explain. Unsure if it's a bug, or I'm misunderstanding the output. I'm running 25.11.b.20251111.2016 on a 6100.

I have 2 "catch all" style rules at the bottom of my LAN interface tab to allow outbound v4 and v6 traffic from the local subnet(s).

When I click the numbers in the States column of the IPv6 rule (to navigate to the Diagnostics → States page) I'm seeing many IPv4 states being captured by this rule. Why is this? Shouldn't having IPv6 selected for Address Family on the rule limit its scope to IPv6 connections only?

As part of my troubleshooting, I thought maybe the builtin "LAN subnets" alias was causing this since it contains both the V4 and the V6 subnet. I created separate aliases explicitly targeting only the V4/V6 ranges respectively, and applied those instead. BUT that did not change this behavior.

Anyone got a clue what's going on here?

Here are those rules straight from rules.debug

# egrep 'inet.? access' /tmp/rules.debug
pass  in  quick  on $LAN inet from $n_LAN_net to any ridentifier 1648647011 keep state label "id=1648647011" label "tags=user_rule" label "descr=inet access"
pass  in  quick  on $LAN inet6 from $n_v6_henet_subnet to any ridentifier 0100000102 keep state label "id=0100000102" label "tags=user_rule" label "descr=inet6 access"

And some screenshots below...

Original rules on LAN tab (using builtin "LAN subnets" alias)

About to click to Diagnostics → States page...

Mix of v4 + v6 states shown even though rule 312 should be scoped to IPV6 only

Here's zeroing in on a specific state (why is this state created by rule 312?)

After explicitly defining separate source v4/v6 subnets (did not change behavior)

[tinfoilmatt]

@luckman212 Can you confirm output of pfctl -vvsr showing that 312 is, in fact, the relevant IPv6-only Rule ID?

Any screencaps of the state table should also include the filtered criteria within the capture.

Preliminarily I'm unable to recreate on CE (2.8.1-RELEASE). But I'm also aware that some ruleset changes, a la rule labels, are being rolled out to development snapshots.

[tinfoilmatt]

pfctl -vvsr | grep @312 would be even better in order to determine if there's more than one Rule ID 312. Apparently, unique Rule IDs are not enforced.

[luckman212]

@tinfoilmatt I've made a couple of changes since posting this, and the rule ID is now @313 but here's the relevant output (confirms this is the one and only rule):

# pfctl -vvsr | grep 'inet6 access'
@313 pass in quick on ix1 inet6 from <n_v6_henet_subnet:1> to any flags S/SA keep state (if-bound) label "id=0100000102" label "tags=user_rule" label "descr=inet6 access" ridentifier 100000102

# pfctl -vvsr | grep @313
@313 pass in quick on ix1 inet6 from <n_v6_henet_subnet:1> to any flags S/SA keep state (if-bound) label "id=0100000102" label "tags=user_rule" label "descr=inet6 access" ridentifier 100000102

[tinfoilmatt]

@luckman212 So that's expected, good. Now how about when you filter state table by "313"?

[tinfoilmatt]

By the way, if you're actively modifying the ruleset, including reloading it, without flushing states in between—I assume that could lead to the apparent 'mixing' of states.

[luckman212]

if you're actively modifying the ruleset, including reloading it, without flushing states in between—I assume that could lead to the apparent 'mixing' of states.

@tinfoilmatt Ah, maybe that's what was happening. I just crashed and core dumped my whole system re-testing the EIM NAT patch (waiting for new kernel to land with @kprovost 's patch) and after the fresh boot, things seem to be working:

[marcosm]

@tinfoilmatt said in IPv4 connections (states) being incorrectly matched by IPv6 rule?:

Apparently, unique Rule IDs are not enforced.

The rule ID referenced there is the "ridentifier" of the rule. The rule ID referenced by the Diagnostics > States page is the rule number. Neither is unique. In the case of the ridentifier, duplicates are only expected with IPv4+IPv6 rules. In the case of the rule number, duplicates are only expected between rule "types" (e.g. scrub, pass/block/match, ethernet) and anchors.

[tinfoilmatt]

@marcosm Appreciate all this clarification. Thanks.