After updating from FreeBSD 9.3-RELEASE #0 r268512 to FreeBSD 10.1-RELEASE #0 r274401, which updated IPFilter from v4.1.28 (400) to v5.1.2 (608) the following command no longer works properly: echo "block in log level local7.info quick on em1 from 218.77.79.55/32 to any" | /sbin/ipf -rf - ; echo "block out log level local7.info quick on em1 from any to 218.77.79.55/32" | /sbin/ipf -rf - ; By works properly I mean- In ipfilter v4.1.28 the command above removes the one matching rule specified in the echo command (which is the expected behavior I believe). In ipfilter v5.1.2 the command above removes the one matching rule specified in the echo command AND every rule leading up to it. Here is an example of what happens in ipfilter v5.1.2 in FreeBSD 10.1-RELEASE: root@perim:~ # ipfstat -lion @1 pass out all @2 block out log level local7.info quick on em1 inet from any to 103.41.124.56/32 @3 block out log level local7.info quick on em1 inet from any to 222.186.59.100/32 @4 block out log level local7.info quick on em1 inet from any to 209.251.180.19/32 @5 block out log level local7.info quick on em1 inet from any to 80.82.70.230/32 @6 block out log level local7.info quick on em1 inet from any to 128.208.4.164/32 @7 block out log level local7.info quick on em1 inet from any to 193.0.129.108/32 @8 block out log level local7.info quick on em1 inet from any to 116.104.186.248/32 @9 block out log level local7.info quick on em1 inet from any to 62.210.95.18/32 @1 pass in all @2 block in log level local7.info quick on em1 inet from 103.41.124.56/32 to any @3 block in log level local7.info quick on em1 inet from 222.186.59.100/32 to any @4 block in log level local7.info quick on em1 inet from 209.251.180.19/32 to any @5 block in log level local7.info quick on em1 inet from 80.82.70.230/32 to any @6 block in log level local7.info quick on em1 inet from 128.208.4.164/32 to any @7 block in log level local7.info quick on em1 inet from 193.0.129.108/32 to any @8 block in log level local7.info quick on em1 inet from 116.104.186.248/32 to any @9 block in log level local7.info quick on em1 inet from 62.210.95.18/32 to any root@perim:~ # echo "block in log level local7.info quick on em1 from 128.208.4.164/32 to any" | /sbin/ipf -rf - ; echo "block out log level local7.info quick on em1 from any to 128.208.4.164/32" | /sbin/ipf -rf - ; root@perim:~ # ipfstat -lion @1 pass out all @2 block out log level local7.info quick on em1 inet from any to 193.0.129.108/32 @3 block out log level local7.info quick on em1 inet from any to 116.104.186.248/32 @4 block out log level local7.info quick on em1 inet from any to 62.210.95.18/32 @1 pass in all @2 block in log level local7.info quick on em1 inet from 193.0.129.108/32 to any @3 block in log level local7.info quick on em1 inet from 116.104.186.248/32 to any @4 block in log level local7.info quick on em1 inet from 62.210.95.18/32 to any In the first command you can see the loaded firewall rules. In the next command the goal is to remove the block in and out for IP address 128.208.4.164. As you can see after running the command for removal, a listing of the loaded firewall rules shows it has deleted every single rule leading up to it. Is this a bug in my syntax, did the syntax change between ipftiler v4.1.28 and v5.1.2? Or is it a bug in ipfilter somewhere?
Tested this locally (using my ruleset and using your ruleset) on a 9.3-RELEASE, on a 10.1-STABLE system, and a 11-CURRENT system. All worked the same, as documented in the man page, removing only one rule. I cannot reproduce this. Can you please perform this test: - ipfstat -io > /tmp/before - echo "some rule" | ipf -rf - - ipfstat -io > /tmp/after - diff /tmp/before /tmp/after Post the output.
(In reply to Cy Schubert from comment #1) root@perim:~ # ipfstat -io > /tmp/before root@perim:~ # echo "block out log level local7.info quick on em1 inet from any to 141.212.122.27/32" | ipf -rf - root@perim:~ # ipfstat -io > /tmp/after root@perim:~ # diff /tmp/before /tmp/after 2,4d1 < block out log level local7.info quick on em1 inet from any to 107.192.96.114/32 < block out log level local7.info quick on em1 inet from any to 62.4.9.18/32 < block out log level local7.info quick on em1 inet from any to 141.212.122.27/32 Has the version of ipf changed between 10.1-RELEASE #0 r274401 and 10.1-STABLE that you tested it on? This is my ipf version information: ipf: IP Filter: v5.1.2 (608) Kernel: IP Filter: v5.1.2 Running: yes Log Flags: 0 = none set Default: pass all, Logging: available Active list: 0 Feature mask: 0x14f
Same version but I merged in some bugfixes from upline (darrenr), NetBSD, and a couple of our own.I suspect the following may be related. r272554 | cy | 2014-10-04 20:52:09 -0700 (Sat, 04 Oct 2014) | 4 lines ipfilter bug #534 destination list hashing not endian neutral Obtained from: ipfilter CVS repo (r1.26), NetBSD CVS repo (r1.8)
r272552 is probably the fix, already in 10-STABLE. ----------------------------------------------------------------------- r272552 | cy | 2014-10-04 20:45:19 -0700 (Sat, 04 Oct 2014) | 5 lines ipfilter bug #554 Determining why a ipf rule matches is hard -- replace ipfilter rule compare with new ipf_rule_compare() function. Obtained from: ipfilter CVS rep (r1.129) ------------------------------------------------------------------------ r272551 | cy | 2014-10-04 20:41:47 -0700 (Sat, 04 Oct 2014) | 4 lines ipfiler bug #550 filter rule list corrupted with inserted rules Obtained from: ipfilter CVS repo (r1.128); NetBSD CVS repo (r1.15) ------------------------------------------------------------------------
(In reply to Cy Schubert from comment #4) Any idea on how long until it hits release or if a patch can be made?
The patch is already in 10-STABLE. 10.2-RELEASE is a few months away. I don't think re@ has announced a 10.2 release schedule yet.
In 10.1-STABLE for a while.