https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796
--- Comment #29 from Cy Schubert <c...@freebsd.org> --- I am only able to reproduce this problem when the on argument is moved ahead of the reply-to. root@ipftest:~ # echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto tcp from any to 10.1.1.11 port = 22 flags S/FSRPAU keep state" | ipf -f - root@ipftest:~ # echo "pass in quick reply-to tun1:10.1.2.1 on tun1 proto tcp from any to 10.1.2.11 port = 22 flags S/FSRPAU keep state" | ipf -f - root@ipftest:~ # echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto tcp from any to 10.1.1.11 port = 22 flags S/FSRPAU keep state" | ipf -f - 32:1:ioctl(add/insert rule): rule already exists root@ipftest:~ # echo "pass in quick on tun0 reply-to tun0:10.1.1.1 proto tcp from any to 10.1.1.11 port = 22 flags S/FSRPAU keep state" | ipf -f - root@ipftest:~ # echo "pass in quick on tun0 reply-to tun0:10.1.1.1 proto tcp from any to 10.1.1.11 port = 22 flags S/FSRPAU keep state" | ipf -f - 32:1:ioctl(add/insert rule): rule already exists root@ipftest:~ # root@ipftest:~ # uname -a FreeBSD ipftest 13.0-CURRENT FreeBSD 13.0-CURRENT r350103 GENERIC amd64 root@ipftest:~ # root@ipftest:~ # kldstat Id Refs Address Size Name 1 9 0xffffffff80200000 24ffe50 kernel 2 1 0xffffffff82819000 2538 intpm.ko 3 1 0xffffffff8281c000 a50 smbus.ko 4 1 0xffffffff8281d000 2498 filemon.ko 5 1 0xffffffff82820000 6baa0 ipl.ko root@ipftest:~ # oot@ipftest:~ # ipfstat -Rion # empty list for ipfilter(out) @1 pass in quick on tun0 reply-to tun0:10.1.1.1 inet proto tcp from any to 10.1.1.11/32 port = 22 flags S/FSRPAU keep state @2 pass in quick on tun1 reply-to tun1:10.1.2.1 inet proto tcp from any to 10.1.2.11/32 port = 22 flags S/FSRPAU keep state @3 pass in quick on tun0 reply-to tun0:10.1.1.1 inet proto tcp from any to 10.1.1.11/32 port = 22 flags S/FSRPAU keep state root@ipftest:~ # root@ipftest:~ # ipf -ZFa root@ipftest:~ # echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto tcp from any to 10.1.1.11 port = 22 flags S/FSRPAU keep state" | ipf -f - root@ipftest:~ # echo "pass in quick reply-to tun1:10.1.2.1 on tun1 proto tcp from any to 10.1.2.11 port = 22 flags S/FSRPAU keep state" | ipf -f - root@ipftest:~ # echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto tcp from any to 10.1.1.11 port = 22 flags S/FSRPAU keep state" | ipf -f - 32:1:ioctl(add/insert rule): rule already exists root@ipftest:~ # root@ipftest:~ # ipfstat -Rion # empty list for ipfilter(out) @1 pass in quick on tun0 reply-to tun0:10.1.1.1 inet proto tcp from any to 10.1.1.11/32 port = 22 flags S/FSRPAU keep state @2 pass in quick on tun1 reply-to tun1:10.1.2.1 inet proto tcp from any to 10.1.2.11/32 port = 22 flags S/FSRPAU keep state root@ipftest:~ # As you can see it rejects the second attempt to load the same rule, however rearranging the on argument (first example) adds a shadowed rule which it should have rejected. This is probably because the additional interface names appended to frentry_t are out of order, causing fr_ifnames to also be out of order. I have yet to test this hypothesis (yet to decide whether to implement a new SDT DTrace probe or simply expose ipf_rule_compare to allow FBT probes). The tests above were using the image on ftp.freebsd.org in a virtualbox vm which itself is running on 13.0-CURRENT. -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
