VLAN Priority when set in a firewall rule, the PASS rule is disrupted

[graphene]

Migrated from 23.09.1 to both:

24.03.r.20240410.1729
24.03.r.20240416.0005

Whenever, there is a rule with PASS where the VLAN priority is set, the traffic is not allowed for some reason. I need to set VLAN priority to "none" in order for the rule to work.

Same configuration in 23.09.1 does not affect the flow of the traffic at all.

Has anything changed that may cause this behavior?

[stephenw10]

So a pass rule on a VLAN that has a priority set? Or a pass rules matching against priority tags? Or passing and setting a priority?

[graphene]

@stephenw10 PASS with priority set

[stephenw10]

Matching or Setting a priority?

[graphene]

@stephenw10 setting the priority

[stephenw10]

I can't replicate that. A pass rule configured to set a priority on matched traffic passes as expected and sets the priority tags:

pass  in  quick  on $LAN inet from $LAN__NETWORK to any ridentifier 0100000101  set prio 5 keep state label "USER_RULE: Default allow LAN to any rule" label "id:0100000101"

15:48:52.600830 00:90:0b:7c:10:58 > 00:08:a2:0c:c9:91, ethertype 802.1Q (0x8100), length 102: vlan 0, p 5, ethertype IPv4 (0x0800), (tos 0x0, ttl 63, id 50626, offset 0, flags [DF], proto ICMP (1), length 84, bad cksum 0 (->a976)!)
    172.21.16.75 > 8.8.8.8: ICMP echo request, id 11711, seq 1, length 64
15:48:52.607588 00:08:a2:0c:c9:91 > 00:90:0b:7c:10:58, ethertype IPv4 (0x0800), length 98: (tos 0x60, ttl 116, id 0, offset 0, flags [none], proto ICMP (1), length 84)
    8.8.8.8 > 172.21.16.75: ICMP echo reply, id 11711, seq 1, length 64

You have a screenshot of the rule?

How are you testing?

[graphene]

@stephenw10 This rules does not work:

This rules does:

I confirm that I do not have any VLAN Prio matching rule in the firewall. And as I explained before, this was working in 23.09.1 and has worked for many years until now.

Testing is done just by making the change, going to the device that belongs to that VLAN and opening a browser to confirm connectivity. In the case of the firewall set as the first screenshot the connection timesout.

[graphene]

@graphene Have also tested removing the Tag clause with same results. The below rule does not work. It does when you set the VLAN prio to "none"

[stephenw10]

Ok to be clear it never passes the traffic? Or doesn't set the priority tag?

Is VLAN99 there actually a VLAN interface on pfSense? I could imagine the tags conflicting somehow.

Do you see states opened by that rule when traffic is not passing?

[graphene]

@stephenw10 Have not made any inspection to the packets to check if the priority is set in the frame, so cannot tell you if the tag is set or not.

What I can tell you is that the traffic does not PASS with VLAN prio set = EE and other values in my particular use case.

The VLAN99 is an actual interface in pfSense, yes.

[graphene]

This is a screenshot of the states on that VLAN after resetting the firewall states and enabling the "not working" rule

[stephenw10]

Is that filtering by the rule number? I have no idea if those states are passed by that rule. You might have other rules on VLAN99.

[graphene]

@stephenw10 Good point. Should have explained. Apologies.

The filter I applied was by IP. All 192.168.199.x devices belong to VLAN99.

And there is only one rule that allows outbound traffic from that VLAN and that is the rule we are discussing here.

There are a couple of states to the DNS server which is commanded by an interface group rule and that seems to have some traffic Ok based on the above screenshot.

Interestingly when I filter by rule Id, I don't get any results.

[stephenw10]

Hmm, so it looks like with the rule configured to set priority it is matching traffic and opening states on both interfaces. But there are no replies implying that traffic is either not leaving the WAN or is blocked by something upstream?

The fact it's opening states on WAN implies it is passing VLAN99.

Can you run a packet capture on WAN and see if that traffic is actually leaving?

[graphene]

@stephenw10 Thank you.

Yes, it seems the traffic is leaving the WAN interface so it must be something upstream.

Interestingly, the same config was working in the previous version. So I wonder if the priority TAG was stripped in 23.09.1 before leaving WAN and now it just continues form the private LAN to WAN.

Cheers

[stephenw10]

Yes it's possible it's now working correctly and was broken before. There have been a bunch of fixes in pf that might have done that, potentially.