[Bug 238796] ipfilter: failure to detect the same rules when arguments ordered differently

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238796

--- Comment #29 from Cy Schubert <cy at FreeBSD.org> ---
I am only able to reproduce this problem when the on argument is moved ahead of
the reply-to.

root at 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 at 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 at 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 at 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 at 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 at ipftest:~ # 
root at ipftest:~ # uname -a
FreeBSD ipftest 13.0-CURRENT FreeBSD 13.0-CURRENT r350103 GENERIC  amd64
root at ipftest:~ # 
root at 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 at ipftest:~ # 
oot at 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 at ipftest:~ # 
root at ipftest:~ # ipf -ZFa
root at 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 at 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 at 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 at ipftest:~ # 
root at 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 at 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.