Date: Fri, 19 Jul 2019 19:56:02 +0000 From: bugzilla-noreply@freebsd.org To: net@FreeBSD.org Subject: [Bug 238796] ipfilter: failure to detect the same rules when arguments ordered differently Message-ID: <bug-238796-7501-snYTMgoIEz@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-238796-7501@https.bugs.freebsd.org/bugzilla/> References: <bug-238796-7501@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D238796 --- Comment #29 from Cy Schubert <cy@FreeBSD.org> --- I am only able to reproduce this problem when the on argument is moved ahea= d of the reply-to. root@ipftest:~ # echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto t= cp from any to 10.1.1.11 port =3D 22 flags S/FSRPAU keep state" | ipf -f - root@ipftest:~ # echo "pass in quick reply-to tun1:10.1.2.1 on tun1 proto t= cp from any to 10.1.2.11 port =3D 22 flags S/FSRPAU keep state" | ipf -f - root@ipftest:~ # echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto t= cp from any to 10.1.1.11 port =3D 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 t= cp from any to 10.1.1.11 port =3D 22 flags S/FSRPAU keep state" | ipf -f - root@ipftest:~ # echo "pass in quick on tun0 reply-to tun0:10.1.1.1 proto t= cp from any to 10.1.1.11 port =3D 22 flags S/FSRPAU keep state" | ipf -f - 32:1:ioctl(add/insert rule): rule already exists root@ipftest:~ #=20 root@ipftest:~ # uname -a FreeBSD ipftest 13.0-CURRENT FreeBSD 13.0-CURRENT r350103 GENERIC amd64 root@ipftest:~ #=20 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:~ #=20 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 =3D 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 =3D 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 =3D 22 flags S/FSRPAU keep state root@ipftest:~ #=20 root@ipftest:~ # ipf -ZFa root@ipftest:~ # echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto t= cp from any to 10.1.1.11 port =3D 22 flags S/FSRPAU keep state" | ipf -f - root@ipftest:~ # echo "pass in quick reply-to tun1:10.1.2.1 on tun1 proto t= cp from any to 10.1.2.11 port =3D 22 flags S/FSRPAU keep state" | ipf -f - root@ipftest:~ # echo "pass in quick reply-to tun0:10.1.1.1 on tun0 proto t= cp from any to 10.1.1.11 port =3D 22 flags S/FSRPAU keep state" | ipf -f - 32:1:ioctl(add/insert rule): rule already exists root@ipftest:~ #=20 root@ipftest:~ # ipfstat -Rion=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20=20= =20=20=20=20=20=20=20=20=20 # 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 =3D 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 =3D 22 flags S/FSRPAU keep state root@ipftest:~ #=20 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 nam= es 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 impleme= nt 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-238796-7501-snYTMgoIEz>