On 24/05/2024 10:23, Alexandr Nedvedicky wrote:
> </snip>
>
>     @0 match in all scrub (no-df random-id)
>     @1 pass out log proto tcp from self to any port 12345
>     @2 anchor "relayd/*"
>     @3 anchor "test" {
> 	@0 pass out log proto tcp from self to any port 12346
> 	@1 anchor "foo" {
> 	    @0 pass out log proto tcp from self to any port 12348
> 	}
> 	@2 pass out log proto tcp from self to any port 12349
>     }
>     @4 pass out log proto tcp from self to any port 12347
>
> Rules above use the same numbering style which is also used by command
>     'pfctl -sr -v' 
>
> if packet is sent to remote port 12349 it matches the rule @2
> in anchor @3 ('test'). pflog (and also state shown by 'pfctl -ss -vv')
> should report that in form:
>     anchor 3, rule 2
> however the pf in current reports this:
>     anchor 1, rule 2
>
>
> </snip>


To extend to the nature of the problem, apart from errors inside anchors the more important is what happens with rules outside/after the anchor.

For instance is sashan's example above,
telnet 1.1.1.1 12347 (first rule after the anchors)
gives

May 24 13:17:48.297961 rule 1/(match) pass out on vio0: xx.xx.xx.xx.17023 > 1.1.1.1.12347: S 2909623631:2909623631(0) win 16384 <mss 1460,nop,nop,sackOK,nop,wscale 6,nop,nop,timestamp 1805612136[|tcp]> (DF) [tos 0x10]

A completely irrelevant rule 1.
It gets the 1 from @1 anchor "foo" which was the last anchor traversed.

all tcp xx.xx.xx.xx:39943 -> 1.1.1.1:12347       SYN_SENT:CLOSED
   [1556986914 + 2]  [0 + 1]
   age 00:00:06, expires in 00:01:54, 1:0 pkts, 64:0 bytes, anchor 1, rule 4
   id: 665061d30000005e creatorid: 3f53707e

Here we have the correct rule number, but a wrong anchor 1.

diff works fine in all my tests and on all releases from 7.2-(after 1.1169) to 7.5-current

In advance, I believe it worths an errata for -release.
After enabling relayd on my main firewall, all my log rules after relayd/* went bananas and are being logged with the rule number of relayd.
I will manually patch if not.

regards,

G