NetBSD Problem Report #56990

From www@netbsd.org  Fri Sep  2 02:07:51 2022
Return-Path: <www@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id A9BEE1A921F
	for <gnats-bugs@gnats.NetBSD.org>; Fri,  2 Sep 2022 02:07:51 +0000 (UTC)
Message-Id: <20220902020749.B0BFD1A923B@mollari.NetBSD.org>
Date: Fri,  2 Sep 2022 02:07:49 +0000 (UTC)
From: hopkinsza@gmail.com
Reply-To: hopkinsza@gmail.com
To: gnats-bugs@NetBSD.org
Subject: npf: `ruleset` line in npf.conf does not behave as expected following a `block all` line
X-Send-Pr-Version: www-1.0

>Number:         56990
>Category:       misc
>Synopsis:       npf: `ruleset` line in npf.conf does not behave as expected following a `block all` line
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    misc-bug-people
>State:          closed
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Sep 02 02:10:00 +0000 2022
>Closed-Date:    Wed Aug 23 20:18:20 +0000 2023
>Last-Modified:  Fri Aug 25 13:50:01 +0000 2023
>Originator:     Zach Hopkins
>Release:        9.3
>Organization:
n/a
>Environment:
NetBSD netbsdvm 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug 4 15:30:37 UTC 2022 mkrepro@mkrepro.NetBSD.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64
>Description:
Discovered when trying to add blacklistd support into my /etc/npf.conf.
Adding the line `ruleset "blacklistd"` in the middle of a configuration block (group "xxx" {...}) in /etc/npf.conf caused everything to be blocked.
Putting that line at the very beginning or end of the block seemed to work as expected (after MUCH frustration of course!).

This actually does not have anything to do with blacklistd, because that npf ruleset was empty (no hosts blocked yet).
The cause was narrowed down to using the `ruleset "blacklistd"` line after `block all` -- with any ruleset name.

For further context, the bug was first discovered on an amd64 VPS running NetBSD 9.3 when trying to use blacklistd with sshd.
The results were further tested and verified using an amd64 NetBSD 9.3 VM in qemu.
>How-To-Repeat:
# echo '
alg "icmp"
group "filtered" on lo0 {
    block all
    ruleset "test"
    pass all
}
group default {
    pass all
}
' >/etc/ntp.conf
# service npf reload
# ping 127.0.0.1
<network unreachable>

The rest of the rule content does not matter; there can be any number of `pass all` and `block all`s in any order.
The ping will not work if there is a `block all` immediately followed by `ruleset "test"` in the config.
The ping wil work if there is a `pass all` immediately followed by `ruleset "test"` in the config.
>Fix:
The `ruleset` line can be moved to the top of the configuration block.

>Release-Note:

>Audit-Trail:
From: mlelstv@serpens.de (Michael van Elst)
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/56990: npf: `ruleset` line in npf.conf does not behave as expected following a `block all` line
Date: Fri, 2 Sep 2022 12:46:20 -0000 (UTC)

 hopkinsza@gmail.com writes:

 >>How-To-Repeat:
 ># echo '
 >alg "icmp"
 >group "filtered" on lo0 {
 >    block all
 >    ruleset "test"
 >    pass all
 >}
 >group default {
 >    pass all
 >}
 >' >/etc/ntp.conf

 The processing is done in npf_ruleset_inspect().

 npf debug -c npf.conf gives:
 ...
 rules (NVLIST ARRAY): 6
     attr (NUMBER): 805306370 (805306370) (0x30000002)
     name (STRING): [filtered]
     ifname (STRING): [lo0]
     prio (NUMBER): 18446744073709551615 (-1) (0xffffffffffffffff)
     skip-to (NUMBER): 4 (4) (0x4)
     ,
     attr (NUMBER): 805306368 (805306368) (0x30000000)
     prio (NUMBER): 18446744073709551615 (-1) (0xffffffffffffffff)
     ,
     attr (NUMBER): 805306434 (805306434) (0x30000042)
     name (STRING): [test]
     prio (NUMBER): 18446744073709551615 (-1) (0xffffffffffffffff)
     ,
     attr (NUMBER): 805306369 (805306369) (0x30000001)
     prio (NUMBER): 18446744073709551615 (-1) (0xffffffffffffffff)
     ,
     attr (NUMBER): 805306370 (805306370) (0x30000002)
     prio (NUMBER): 18446744073709551615 (-1) (0xffffffffffffffff)
     skip-to (NUMBER): 6 (6) (0x6)
     ,
     attr (NUMBER): 805306369 (805306369) (0x30000001)
     prio (NUMBER): 18446744073709551615 (-1) (0xffffffffffffffff)

 Slightly transliterated:

 1: GROUP inout (name="filtered", ifname="lo0", prio=-1, skip-to=4)
 -> if this matches (interface) continue else goto rule 4

 2: BLOCK inout (prio=-1)
 -> set result to BLOCK but continue

 3: DYNAMIC_GROUP inout (name="test", prio=-1)
 -> a DYNAMIC_GROUP is also a GROUP and we already have a result, just exit

 4: PASS inout (prio=-1)
 5: GROUP inout (prio=-1, skip-to=6)
 6: PASS inout (prio=-1)

 When you move DYNAMIC_GROUP to position 2, it is actually
 evaluated as there is no result yet.


 The bug is that evaluation of a ruleset exits when seeing any GROUP
 rule. A regular GROUP rule is the start of the next ruleset, aborting
 here if you have a result is correct.
 But a DYNAMIC_GROUP (== evaluation of another "sub"-ruleset) should
 not be a barrier for evaluation.

From: "Frank Kardel" <kardel@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56990 CVS commit: src/sys/net/npf
Date: Tue, 8 Aug 2023 16:10:42 +0000

 Module Name:	src
 Committed By:	kardel
 Date:		Tue Aug  8 16:10:42 UTC 2023

 Modified Files:
 	src/sys/net/npf: npf_ruleset.c

 Log Message:
 The analysis documented in PR misc/56990 is correct.
 Fix by not returning when encountering a ruleset rule.

 The code up to now would stop at any group rule.

 ruleset rules are marked as group rule and a dynamic rule.

 processing is only finished when a result is present AND
 we are looking at a plain group rule.


 To generate a diff of this commit:
 cvs rdiff -u -r1.51 -r1.52 src/sys/net/npf/npf_ruleset.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Frank Kardel <kardel@kardel.name>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/56990: npf: `ruleset` line in npf.conf does not behave as
 expected following a `block all` line
Date: Tue, 8 Aug 2023 18:20:39 +0200

 Zach, can you please verify?

State-Changed-From-To: open->feedback
State-Changed-By: kardel@NetBSD.org
State-Changed-When: Tue, 08 Aug 2023 16:26:19 +0000
State-Changed-Why:
fix committed


From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/56990 (npf: `ruleset` line in npf.conf does not behave as
 expected following a `block all` line)
Date: Wed, 23 Aug 2023 13:36:23 +0200

 pullup-8
 pullup-9
 pullup-10

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/56990 (npf: `ruleset` line in npf.conf does not behave as
 expected following a `block all` line)
Date: Wed, 23 Aug 2023 13:56:35 +0200

 [pullup-10 #340]
 [pullup-9 #1725]
 [pullup-8 #1893]

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56990 CVS commit: [netbsd-10] src/sys/net/npf
Date: Wed, 23 Aug 2023 18:19:32 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Aug 23 18:19:32 UTC 2023

 Modified Files:
 	src/sys/net/npf [netbsd-10]: npf_ruleset.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #340):

 	sys/net/npf/npf_ruleset.c: revision 1.52

 The analysis documented in PR misc/56990 is correct.

 Fix by not returning when encountering a ruleset rule.

 The code up to now would stop at any group rule.
 ruleset rules are marked as group rule and a dynamic rule.
 processing is only finished when a result is present AND
 we are looking at a plain group rule.


 To generate a diff of this commit:
 cvs rdiff -u -r1.51 -r1.51.20.1 src/sys/net/npf/npf_ruleset.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56990 CVS commit: [netbsd-9] src/sys/net/npf
Date: Wed, 23 Aug 2023 18:22:51 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Aug 23 18:22:51 UTC 2023

 Modified Files:
 	src/sys/net/npf [netbsd-9]: npf_ruleset.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #1725):

 	sys/net/npf/npf_ruleset.c: revision 1.52

 The analysis documented in PR misc/56990 is correct.

 Fix by not returning when encountering a ruleset rule.

 The code up to now would stop at any group rule.
 ruleset rules are marked as group rule and a dynamic rule.
 processing is only finished when a result is present AND
 we are looking at a plain group rule.


 To generate a diff of this commit:
 cvs rdiff -u -r1.48.2.3 -r1.48.2.4 src/sys/net/npf/npf_ruleset.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/56990 CVS commit: [netbsd-8] src/sys/net/npf
Date: Wed, 23 Aug 2023 18:25:04 +0000

 Module Name:	src
 Committed By:	martin
 Date:		Wed Aug 23 18:25:04 UTC 2023

 Modified Files:
 	src/sys/net/npf [netbsd-8]: npf_ruleset.c

 Log Message:
 Pull up following revision(s) (requested by kardel in ticket #1893):

 	sys/net/npf/npf_ruleset.c: revision 1.52

 The analysis documented in PR misc/56990 is correct.

 Fix by not returning when encountering a ruleset rule.

 The code up to now would stop at any group rule.
 ruleset rules are marked as group rule and a dynamic rule.
 processing is only finished when a result is present AND
 we are looking at a plain group rule.


 To generate a diff of this commit:
 cvs rdiff -u -r1.45 -r1.45.6.1 src/sys/net/npf/npf_ruleset.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

State-Changed-From-To: feedback->closed
State-Changed-By: kardel@NetBSD.org
State-Changed-When: Wed, 23 Aug 2023 20:18:20 +0000
State-Changed-Why:
pullups done. thanks!


From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: misc/56990: npf: `ruleset` line in npf.conf does not behave as
 expected following a `block all` line
Date: Fri, 25 Aug 2023 12:34:03 +0200

 	Hello,

 	PR/56990 seems to broke a running configuration on -10_beta.

 Network configuration:
 - wm0 and wm1 : bridge0 (192.168.12.1/24) connected to two NAS (iSCSI)
 - wm2 : WAN (public address)
 - wm3 and wm4 : lagg0 (192.168.10.128/24) connected to LAN
 - re0 : DMZ (192.168.1.1/24)

 wm0 and wm1 are two Ethernet connectors on the same I350 adapter (one
 connector for a NAS, connected without switch).

 	Until last patches, my server runs with the following npf.conf. I use
 video_if and bacula_if as npf doesn't understand bridge0.

 $lan_if = "lagg0"
 $wan_if = "wm2"
 $bacula_if = "wm1"
 $video_if = "wm0"
 $ext_v4 = inet4($wan_if)
 $dmz_if = "re0"

 set bpf.jit on;
 alg "icmp"

 # Outgoing NAT
 map inet4($wan_if) dynamic 192.168.10.0/24 -> $ext_v4
 map inet4($wan_if) dynamic 192.168.12.0/24 -> $ext_v4

 procedure "log" {
     log: npflog0
 }

 group "wan" on $wan_if {
     ruleset "blocklistd"

     # ICMP
     pass in final family inet4 proto icmp all
     pass out final family inet4 proto icmp all

 ...

     # Default
     block final all
 }

 group "lan" on $lan_if {
     pass final all
 }

 group "dmz" on $dmz_if {
     pass in final family inet4 proto icmp all
     pass out final family inet4 proto icmp all

     # ssh
     pass stateful out final family inet4 proto tcp from any \
             to any port ssh
     pass stateful in final family inet4 proto tcp from any \
             to any port ssh

 ...
     block final all
 }

 group "bacula" on $bacula_if {
     pass final all
 }


 group "video" on $video_if {
     pass final all
 }

 group default {
     pass final on lo0 all
     block all
 }

 	Now, I have to replace group default by :

 group default {
     pass final on lo0 all
     pass all
 }

 if I want to access to both NAS. With "block all", only the first NAS
 can be connected to server with iSCSI but both answer to ping.

 	Best regards,

 	JKB

From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/56990: npf: `ruleset` line in npf.conf does not behave as
 expected following a `block all` line
Date: Fri, 25 Aug 2023 13:14:19 +0200

 Hi,

 This is a strange behavior.

 Given that change to the default group change the behavior I suspect 
 that the

 packets from are not matched by the group definitions for wm0 and wm1.

 There are some things to help the analysis.

      1) add 'apply "log"' to the block rules and

        do "tcpdump -v -e -i npflog0"

        This should list which rule (presumably the default group) is the 
 blocking cause and the related interface.

        The rule numbers can be found by running "npfctl show"

      2) bridge0 is a non-trivial interface especially when packets 
 arrive on an interface without

        ip addresses but matching a local ip address it may be that NPF 
 sees bridge0 as incoming

        interface that is why 1) is important. If it sees bridge0 as 
 incoming interface it is no wonder

        why packets will be blocked by the unmodifies default rule.

      3) "brconfig bridge0 ipf" enables the packet filter - this may 
 enable NPF to react correctly

        to packets passing bridge0

      4) You could revert the patch to npf_ruleset.c to see whether that 
 makes a difference.

         I currently have yet to understand why the fix in npf_ruleset.c 
 changes the rule set matching.

 Frank

From: =?UTF-8?Q?BERTRAND_Jo=c3=abl?= <joel.bertrand@systella.fr>
To: "gnats-bugs@netbsd.org" <gnats-bugs@NetBSD.org>
Cc: 
Subject: Re: misc/56990: npf: `ruleset` line in npf.conf does not behave as
 expected following a `block all` line
Date: Fri, 25 Aug 2023 15:12:01 +0200

 	Strange.

 	I have tried to add log without any result.

 1/ I have unmounted iSCSI device (unmount and iscsictl logout)
 2/ I have modified my /etc/npf.conf file:

 group default {
     pass final on lo0 all
     block all apply "log"
 }

 3/ I have reconnected iSCSI targets (iscsctl
 add_send_target/refresh_target/login). These commands are in a script,
 thus, I have reconnected these devices with /exactly/ the same sequence
 of commands :

 case $1 in
 start)
     sleep 5
     ${command} add_send_target -a 192.168.12.2
     ${command} add_send_target -a 192.168.12.3
     ${command} refresh_targets
     ${command} list_targets
     ${command} login -P `iscsictl list_targets | \
         awk '/192.168.12.2/ { print $1; }' | tr -d ":"`
     ${command} login -P `iscsictl list_targets | \
         awk '/192.168.12.3/ { print $1; }' | tr -d ":"`
     sleep 1
     mount -o rw,log NAME=bacula /opt/bacula
     mount -o rw,log NAME=video /opt/video
     /etc/rc.d/mountd reload

 and... both devices are now connected, mounted and usable. I don't
 undestand, this morning, I have tried to connect these devices without
 success. I cannot reboot this server to test again but I will restart
 system as soon as possible to check.

 	I have added !brconfig $int ipf at end of ifconfig.bridge0 but both
 devices run without this line.

 	Regards,

 	JKB

From: Frank Kardel <kardel@netbsd.org>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: misc/56990: npf: `ruleset` line in npf.conf does not behave as
 expected following a `block all` line
Date: Fri, 25 Aug 2023 15:49:18 +0200

 Hi !

 Looks like npf_ruleset.c is not the culprit. That patch was unlikely to 
 begin with to be the cause for
 executing the default group rules. So the behavior you saw with the 
 default group is most likely
 caused by other circumstances and needs further investigation.

 Frank

>Unformatted:

Home	PR Database Search