From owner-freebsd-ipfw@FreeBSD.ORG Tue Sep 30 00:28:20 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E4EB43AF for ; Tue, 30 Sep 2014 00:28:20 +0000 (UTC) Received: from m.nyi.net (m.nyi.net [66.111.12.250]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BBC26EDF for ; Tue, 30 Sep 2014 00:28:20 +0000 (UTC) Received: from m.nyi.net (localhost [127.0.0.1]) by m.nyi.net (Postfix) with ESMTP id 7C246108984 for ; Mon, 29 Sep 2014 20:22:07 -0400 (EDT) Received: from m.nyi.net ([127.0.0.1]) by m.nyi.net (m.nyi.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vsb8UbG-t+Cs for ; Mon, 29 Sep 2014 20:21:59 -0400 (EDT) Received: from [10.50.50.235] (urchin.nyi.net [64.147.100.2]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: jacob@nyi.net) by m.nyi.net (Postfix) with ESMTPSA id 031411088E8 for ; Mon, 29 Sep 2014 20:21:59 -0400 (EDT) Message-ID: <5429F7A6.3060701@nyi.net> Date: Mon, 29 Sep 2014 20:21:58 -0400 From: Jack Barber Organization: New York Internet Company User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: trouble with ipfw on FreeBSD 10 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 00:28:21 -0000 We are having trouble getting ipfw to work over a bridged interface. for example: machine 1 -> Bridged interface FreeBSD 10 -> machine 2. machine 1 - 192.168.20.20 machine 2 - 192.168.20.25 now I set something like this in /etc/ipfw.rules: $IPFWcmd add deny all from 192.168.20.20/24 to any $IPFWcmd add deny all from any to 192.168.20.20/24 where both machine 1 and machine 2 are on said subnet and already work. when I reload the rules, I am unable to stop a connection between machine 1 and machine 2. I've already made sure that ipfw is running(loaded), and the rules appear to take, and even show up with "ipfw show". # ipfw show ... 01700 0 0 deny ip from 192.168.20.0/24 to any 01800 0 0 deny ip from any to 192.168.20.0/24 65535 9227 11389032 allow ip from any to any However, there is no effect on data travelling over the pipe at all. This setup was confirmed many times to work with FreeBSD 9.2, but it does not work on 10. any help is appreciated. From owner-freebsd-ipfw@FreeBSD.ORG Tue Sep 30 05:29:22 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CFA4A7F6 for ; Tue, 30 Sep 2014 05:29:22 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47FEEC34 for ; Tue, 30 Sep 2014 05:29:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s8U5TCpK073373; Tue, 30 Sep 2014 15:29:12 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 30 Sep 2014 15:29:11 +1000 (EST) From: Ian Smith To: Jack Barber Subject: Re: trouble with ipfw on FreeBSD 10 In-Reply-To: <5429F7A6.3060701@nyi.net> Message-ID: <20140930150819.Y48482@sola.nimnet.asn.au> References: <5429F7A6.3060701@nyi.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 05:29:22 -0000 On Mon, 29 Sep 2014 20:21:58 -0400, Jack Barber wrote: > We are having trouble getting ipfw to work over a bridged interface. > > for example: > > machine 1 -> Bridged interface FreeBSD 10 -> machine 2. > > machine 1 - 192.168.20.20 > machine 2 - 192.168.20.25 > > now I set something like this in /etc/ipfw.rules: > > $IPFWcmd add deny all from 192.168.20.20/24 to any > $IPFWcmd add deny all from any to 192.168.20.20/24 > > where both machine 1 and machine 2 are on said subnet and already work. Please confirm that these two are only connected via two interfaces on the bridge/ipfw box, with no switch involved? And that these rules, once working, should deny traffic between ANY hosts in this /24 subnet? > when I reload the rules, I am unable to stop a connection between > machine 1 and machine 2. > > I've already made sure that ipfw is running(loaded), and the rules > appear to take, and even show up with "ipfw show". > > # ipfw show > ... > 01700 0 0 deny ip from 192.168.20.0/24 to any > 01800 0 0 deny ip from any to 192.168.20.0/24 > 65535 9227 11389032 allow ip from any to any > > However, there is no effect on data travelling over the pipe at all. > > This setup was confirmed many times to work with FreeBSD 9.2, but it > does not work on 10. any help is appreciated. What values are set for these sysctls? net.link.ether.ipfw: 0 Controls whether layer-2 packets are passed to ipfw. Default is no. net.link.bridge.ipfw: 0 Controls whether bridged packets are passed to ipfw. Default is no. cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Wed Oct 1 05:55:35 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EEADD167 for ; Wed, 1 Oct 2014 05:55:35 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 423F99A7 for ; Wed, 1 Oct 2014 05:55:34 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s915sv0E027057; Wed, 1 Oct 2014 15:54:57 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 1 Oct 2014 15:54:57 +1000 (EST) From: Ian Smith To: Jack Barber Subject: Re: trouble with ipfw on FreeBSD 10 In-Reply-To: <542B34A5.2030505@nyi.net> Message-ID: <20141001153412.R48482@sola.nimnet.asn.au> References: <5429F7A6.3060701@nyi.net> <20140930150819.Y48482@sola.nimnet.asn.au> <542B34A5.2030505@nyi.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 05:55:36 -0000 On Tue, 30 Sep 2014 18:54:29 -0400, Jack Barber wrote: > On 09/30/2014 01:29 AM, Ian Smith wrote: > > On Mon, 29 Sep 2014 20:21:58 -0400, Jack Barber wrote: > > > We are having trouble getting ipfw to work over a bridged interface. > > > > > > for example: > > > > > > machine 1 -> Bridged interface FreeBSD 10 -> machine 2. > > > > > > machine 1 - 192.168.20.20 > > > machine 2 - 192.168.20.25 > > > > > > now I set something like this in /etc/ipfw.rules: > > > > > > $IPFWcmd add deny all from 192.168.20.20/24 to any > > > $IPFWcmd add deny all from any to 192.168.20.20/24 > > > > > > where both machine 1 and machine 2 are on said subnet and already work. > > > > Please confirm that these two are only connected via two interfaces on > > the bridge/ipfw box, with no switch involved? And that these rules, > > once working, should deny traffic between ANY hosts in this /24 subnet? > > > > > when I reload the rules, I am unable to stop a connection between > > > machine 1 and machine 2. > > > > > > I've already made sure that ipfw is running(loaded), and the rules > > > appear to take, and even show up with "ipfw show". > > > > > > # ipfw show > > > ... > > > 01700 0 0 deny ip from 192.168.20.0/24 to any > > > 01800 0 0 deny ip from any to 192.168.20.0/24 > > > 65535 9227 11389032 allow ip from any to any > > > > > > However, there is no effect on data travelling over the pipe at all. > > > > > > This setup was confirmed many times to work with FreeBSD 9.2, but it > > > does not work on 10. any help is appreciated. > > > > What values are set for these sysctls? > > > > net.link.ether.ipfw: 0 > > Controls whether layer-2 packets are passed to ipfw. Default is > > no. > > > > net.link.bridge.ipfw: 0 > > Controls whether bridged packets are passed to ipfw. Default is > > no. > > > > cheers, Ian > > on 192.168.20.0/24 the network was set up soley as a test network. It is > compromised of two load-generating machines on either side(192.168.20.20 > and 192.168.20.25), and a FreeBSD 10 machine in the middle which has a > double headed fibre nic bridged to connect both machines through the > FreeBSD 10 machine. > > # sysctl net.link.bridge.ipfw > net.link.bridge.ipfw: 1 > > # sysctl net.link.ether.ipfw > net.link.ether.ipfw: 0 > > > furthermore, I am unable to find a good guide or refrence material to > sysctl options. Jack, I'm posting this back to the list. I haven't set up a filtering bridge since about 2005, and that was with the old bridge(?) on FreeBSD 4.8 and 4.10, rather than if_bridge(4). I really can't recall whether net.link.ether.ipfw also needed to be set. Since 'bridged' is a synonym for 'layer2', I'm not clear from ipfw(8) either .. nor from if_bridge(4), especially regarding use of the net.link.bridge.pfil_* sysctls - but some people here will know .. cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 2 07:39:59 2014 Return-Path: Delivered-To: ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB9943EA; Thu, 2 Oct 2014 07:39:58 +0000 (UTC) Received: from mail.allbsd.org (gatekeeper.allbsd.org [IPv6:2001:2f0:104:e001::32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.allbsd.org", Issuer "RapidSSL CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EA19361A; Thu, 2 Oct 2014 07:39:57 +0000 (UTC) Received: from alph.d.allbsd.org ([IPv6:2001:2f0:104:e010:862b:2bff:febc:8956]) (authenticated bits=56) by mail.allbsd.org (8.14.9/8.14.8) with ESMTP id s927dWGN075272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 2 Oct 2014 16:39:42 +0900 (JST) (envelope-from hrs@FreeBSD.org) Received: from localhost (localhost [IPv6:::1]) (authenticated bits=0) by alph.d.allbsd.org (8.14.8/8.14.8) with ESMTP id s927dTHo017073; Thu, 2 Oct 2014 16:39:31 +0900 (JST) (envelope-from hrs@FreeBSD.org) Date: Thu, 02 Oct 2014 16:39:13 +0900 (JST) Message-Id: <20141002.163913.1611863032602700090.hrs@allbsd.org> To: julian@freebsd.org Subject: Re: net.inet{,6}.fw.enable in /etc/rc From: Hiroki Sato In-Reply-To: <542155FB.9020801@freebsd.org> References: <20140921.145812.325633000583440554.hrs@allbsd.org> <542063F3.8080600@yandex.ru> <542155FB.9020801@freebsd.org> X-PGPkey-fingerprint: BDB3 443F A5DD B3D0 A530 FFD7 4F2C D3D8 2793 CF2D X-Mailer: Mew version 6.6 on Emacs 24.3 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Multipart/Signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="--Security_Multipart(Thu_Oct__2_16_39_13_2014_926)--" Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97.4 at gatekeeper.allbsd.org X-Virus-Status: Clean X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.4.3 (mail.allbsd.org [IPv6:2001:2f0:104:e001::32]); Thu, 02 Oct 2014 16:39:52 +0900 (JST) X-Spam-Status: No, score=-97.9 required=13.0 tests=CONTENT_TYPE_PRESENT, RDNS_NONE,SPF_SOFTFAIL,USER_IN_WHITELIST autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on gatekeeper.allbsd.org Cc: bu7cher@yandex.ru, ipfw@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 07:39:59 -0000 ----Security_Multipart(Thu_Oct__2_16_39_13_2014_926)-- Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Julian Elischer wrote in <542155FB.9020801@freebsd.org>: ju> On 9/23/14, 2:01 AM, Andrey V. Elsukov wrote: ju> > On 21.09.2014 09:58, Hiroki Sato wrote: ju> >> Hi, ju> >> ju> >> I would like your comments about the attached patch to /etc/rc. ju> >> ju> >> The problem I want to fix by this patch is as follows. ju> >> net.inet{,6}.fw.enable are set to 1 by default at boot time if IPFW ju> >> kernel module is loaded or statically compiled into a kernel. And by ju> >> default IPFW has only a "deny ip from any to any" rule if it is ju> >> compiled without IPFIREWALL_DEFAULT_TO_ACCEPT option. In this case, ju> >> the default-deny rule can prevent rc.d scripts before rc.d/ipfw from ju> >> working as described in the patch. ju> >> ju> >> To fix this, the patch turns IPFW off before running rc.d scripts at ju> >> boot time, and enables it again in rc.d/ipfw script. ju> > Hi, ju> > ju> > I think this should be configurable, the change can be an unexpected ju> > for ju> > someone. ju> it does open a window where there is networking but no firewalling. ju> given that a reboot is remotely detectable. (ping stops responding ju> etc.) ju> there is a possibility that a targeted attack could include ju> "use exploit ABC to cause a crash of the target and then strike with ju> exploit XYZ after target system reboots while the firewall is ju> disabled". ju> ju> I have not evaluated the danger of this window. Yes, certainly this opens a window between rc.d/netif to rc.d/ipfw. I admit it is a problem of disabling IPFW unconditionally. Does ipfw have rules which depend on interface initialization? If not, moving rc.d/ipfw to just before rc.d/netif may be a better idea. -- Hiroki ----Security_Multipart(Thu_Oct__2_16_39_13_2014_926)-- Content-Type: application/pgp-signature Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEABECAAYFAlQtASEACgkQTyzT2CeTzy3C0ACg1/0QZw6356lpzy+X3cJQG19C EuUAoIswuh1kKzT5+8G9OmURSVk5l7F5 =I4WB -----END PGP SIGNATURE----- ----Security_Multipart(Thu_Oct__2_16_39_13_2014_926)---- From owner-freebsd-ipfw@FreeBSD.ORG Thu Oct 2 19:12:37 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DF446854; Thu, 2 Oct 2014 19:12:36 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4342A284; Thu, 2 Oct 2014 19:12:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s92JCPQm005803; Fri, 3 Oct 2014 05:12:25 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 3 Oct 2014 05:12:25 +1000 (EST) From: Ian Smith To: Hiroki Sato Subject: Re: net.inet{,6}.fw.enable in /etc/rc In-Reply-To: <20141002.163913.1611863032602700090.hrs@allbsd.org> Message-ID: <20141003025830.D48482@sola.nimnet.asn.au> References: <20140921.145812.325633000583440554.hrs@allbsd.org> <542063F3.8080600@yandex.ru> <542155FB.9020801@freebsd.org> <20141002.163913.1611863032602700090.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: bu7cher@yandex.ru, julian@freebsd.org, ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Oct 2014 19:12:37 -0000 On Thu, 2 Oct 2014 16:39:13 +0900, Hiroki Sato wrote: > Julian Elischer wrote > in <542155FB.9020801@freebsd.org>: > > ju> On 9/23/14, 2:01 AM, Andrey V. Elsukov wrote: > ju> > On 21.09.2014 09:58, Hiroki Sato wrote: > ju> >> Hi, > ju> >> > ju> >> I would like your comments about the attached patch to /etc/rc. > ju> >> > ju> >> The problem I want to fix by this patch is as follows. > ju> >> net.inet{,6}.fw.enable are set to 1 by default at boot time if IPFW > ju> >> kernel module is loaded or statically compiled into a kernel. And by > ju> >> default IPFW has only a "deny ip from any to any" rule if it is > ju> >> compiled without IPFIREWALL_DEFAULT_TO_ACCEPT option. In this case, > ju> >> the default-deny rule can prevent rc.d scripts before rc.d/ipfw from > ju> >> working as described in the patch. > ju> >> > ju> >> To fix this, the patch turns IPFW off before running rc.d scripts at > ju> >> boot time, and enables it again in rc.d/ipfw script. > ju> > Hi, > ju> > > ju> > I think this should be configurable, the change can be an unexpected > ju> > for > ju> > someone. > ju> it does open a window where there is networking but no firewalling. > ju> given that a reboot is remotely detectable. (ping stops responding > ju> etc.) > ju> there is a possibility that a targeted attack could include > ju> "use exploit ABC to cause a crash of the target and then strike with > ju> exploit XYZ after target system reboots while the firewall is > ju> disabled". > ju> > ju> I have not evaluated the danger of this window. > > Yes, certainly this opens a window between rc.d/netif to rc.d/ipfw. > I admit it is a problem of disabling IPFW unconditionally. Well, being only an issue when ipfw is compiled into kernel (without DEFAULT_TO_ACCEPT) or deliberately preloaded in /boot/loader.conf, we can a) determine whether net.inet.ip.fw.enable is set and only if so, b) add rule/s to enable only DHCP, perhaps something like (tested here): if [ "`sysctl -ni net.inet.ip.fw.enable`" = "1" ]; then # "0" if ipfw loaded but disabled or "" if not loaded echo "firewall already enabled - allowing DHCP only" ipfw add 65534 allow udp from me to any 67 out ipfw add 65534 allow udp from any 67 to me in else echo "ipfw not loaded .. doing nothing" fi which rules will be flushed when /etc/rc.d/ipfw runs, but should enable DHCP to work? I'm not sure whether those rules are exactly correct or sufficient for DHCP, but principle is to anly allow what's necessary in the circumstances this addresses, vastly reducing vulnerable window. Using such a method, there should be no need to modify rc.d/ipfw? > Does ipfw have rules which depend on interface initialization? If > not, moving rc.d/ipfw to just before rc.d/netif may be a better idea. It can. If using (say) mpd with dialup or ADSL modems, as I do, the interface - here ng0 - needs to preexist, needing an IP address too. I think that by now, many will likely rely on netif preceding ipfw. > -- Hiroki cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Sat Oct 4 07:51:04 2014 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7F10E289 for ; Sat, 4 Oct 2014 07:51:04 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E09E8F4A for ; Sat, 4 Oct 2014 07:51:00 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s947omIj082355; Sat, 4 Oct 2014 17:50:49 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 4 Oct 2014 17:50:48 +1000 (EST) From: Ian Smith To: Jack Barber Subject: Re: trouble with ipfw on FreeBSD 10 In-Reply-To: <20141001153412.R48482@sola.nimnet.asn.au> Message-ID: <20141004172254.G56328@sola.nimnet.asn.au> References: <5429F7A6.3060701@nyi.net> <20140930150819.Y48482@sola.nimnet.asn.au> <542B34A5.2030505@nyi.net> <20141001153412.R48482@sola.nimnet.asn.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 07:51:04 -0000 On Wed, 1 Oct 2014 15:54:57 +1000, Ian Smith wrote: > On Tue, 30 Sep 2014 18:54:29 -0400, Jack Barber wrote: > > On 09/30/2014 01:29 AM, Ian Smith wrote: > > > On Mon, 29 Sep 2014 20:21:58 -0400, Jack Barber wrote: > > > > We are having trouble getting ipfw to work over a bridged interface. > > > > > > > > for example: > > > > > > > > machine 1 -> Bridged interface FreeBSD 10 -> machine 2. > > > > > > > > machine 1 - 192.168.20.20 > > > > machine 2 - 192.168.20.25 > > > > > > > > now I set something like this in /etc/ipfw.rules: > > > > > > > > $IPFWcmd add deny all from 192.168.20.20/24 to any > > > > $IPFWcmd add deny all from any to 192.168.20.20/24 > > > > > > > > where both machine 1 and machine 2 are on said subnet and already work. > > > > > > Please confirm that these two are only connected via two interfaces on > > > the bridge/ipfw box, with no switch involved? And that these rules, > > > once working, should deny traffic between ANY hosts in this /24 subnet? > > > > > > > when I reload the rules, I am unable to stop a connection between > > > > machine 1 and machine 2. > > > > > > > > I've already made sure that ipfw is running(loaded), and the rules > > > > appear to take, and even show up with "ipfw show". > > > > > > > > # ipfw show > > > > ... > > > > 01700 0 0 deny ip from 192.168.20.0/24 to any > > > > 01800 0 0 deny ip from any to 192.168.20.0/24 > > > > 65535 9227 11389032 allow ip from any to any > > > > > > > > However, there is no effect on data travelling over the pipe at all. > > > > > > > > This setup was confirmed many times to work with FreeBSD 9.2, but it > > > > does not work on 10. any help is appreciated. > > > > > > What values are set for these sysctls? > > > > > > net.link.ether.ipfw: 0 > > > Controls whether layer-2 packets are passed to ipfw. Default is > > > no. > > > > > > net.link.bridge.ipfw: 0 > > > Controls whether bridged packets are passed to ipfw. Default is > > > no. > > > > > > cheers, Ian > > > > on 192.168.20.0/24 the network was set up soley as a test network. It is > > compromised of two load-generating machines on either side(192.168.20.20 > > and 192.168.20.25), and a FreeBSD 10 machine in the middle which has a > > double headed fibre nic bridged to connect both machines through the > > FreeBSD 10 machine. > > > > # sysctl net.link.bridge.ipfw > > net.link.bridge.ipfw: 1 > > > > # sysctl net.link.ether.ipfw > > net.link.ether.ipfw: 0 > > > > > > furthermore, I am unable to find a good guide or refrence material to > > sysctl options. > > Jack, I'm posting this back to the list. I haven't set up a filtering > bridge since about 2005, and that was with the old bridge(?) on FreeBSD > 4.8 and 4.10, rather than if_bridge(4). I really can't recall whether > net.link.ether.ipfw also needed to be set. > > Since 'bridged' is a synonym for 'layer2', I'm not clear from ipfw(8) > either .. nor from if_bridge(4), especially regarding use of the > net.link.bridge.pfil_* sysctls - but some people here will know .. They will know, but that doesn't mean that they'll say :) I dug up the old filtering bridge setup, used from 2003-2009, and things were rather different with the old bridge(4); here's its sysctl.conf: net.link.ether.bridge_cfg=rl0,vr0 net.link.ether.bridge=1 net.link.ether.bridge_ipfw=1 Also, in those days, you could only filter bridged packets on the way in; once passed inbound they never were passed to ipfw again .. I don't know if that's still the case with if_bridge(4), but I assume not (?) However looking at ipfw(8) PACKET FLOW, it seems likely that you'd need to also set net.link.ether.ipfw=1 to pass bridged / layer2 packets to ipfw. You might see if that helps? You could also add something like the rules at the end of that section to check inbound/outbound packet flow at both layer2 and layer3, even if just with 'count' rules. I don't disagree that documentation of this aspect is, er, thin. cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Sat Oct 4 12:37:04 2014 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B56562A; Sat, 4 Oct 2014 12:37:04 +0000 (UTC) Received: from mail.ipfw.ru (mail.ipfw.ru [IPv6:2a01:4f8:120:6141::2]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2812FD2B; Sat, 4 Oct 2014 12:37:04 +0000 (UTC) Received: from [2a02:6b8:0:401:222:4dff:fe50:cd2f] (helo=ptichko.yndx.net) by mail.ipfw.ru with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.82 (FreeBSD)) (envelope-from ) id 1XaKaj-000O7E-Ql; Sat, 04 Oct 2014 12:21:25 +0400 Message-ID: <542FE9A7.9090208@FreeBSD.org> Date: Sat, 04 Oct 2014 16:35:51 +0400 From: "Alexander V. Chernikov" User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.1.2 MIME-Version: 1.0 To: "freebsd-net@freebsd.org" , freebsd-ipfw , freebsd-current@freebsd.org Subject: HEADS UP: Merging projects/ipfw to HEAD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Luigi Rizzo X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Oct 2014 12:37:04 -0000 Hi, I'm going to merge projects/ipfw branch to HEAD in the middle of next week. What has changed: Main user-visible changes are related to tables: * Tables are now identified by names, not numbers. There can be up to 65k tables with up to 63-byte long names. * Tables are now set-aware (default off), so you can switch/move them atomically with rules. * More functionality is supported (swap, lock, limits, user-level lookup, batched add/del) by generic table code. * New table types are added (flow) so you can match multiple packet fields at once. * Ability to add different type of lookup algorithms for particular table type has been added. * New table algorithms are added (cidr:hash, iface:array, number:array and flow:hash) to make certain types of lookup more effective. * Table value are now capable of holding multiple data fields for different tablearg users Some examples (see ipfw(8) manual page for the description): 0:02 [2] zfscurr0# ipfw table fl2 create type flow:src-ip,proto,dst-port algo flow:hash valtype skipto,fib 0:02 [2] zfscurr0# ipfw table fl2 info +++ table(fl2), set(0) +++ kindex: 0, type: flow:src-ip,proto,dst-port valtype: number, references: 0 algorithm: flow:hash items: 0, size: 280 0:02 [2] zfscurr0# ipfw table fl2 add 2a02:6b8::333,tcp,443 45000,12 0:02 [2] zfscurr0# ipfw table fl2 add 10.0.0.92,tcp,80 22000,13 0:02 [2] zfscurr0# ipfw table fl2 list +++ table(fl2), set(0) +++ 2a02:6b8::333,6,443 45000 10.0.0.92,6,80 22000 0:02 [2] zfscurr0# ipfw add 200 count tcp from me to 78.46.89.105 80 flow 'table(fl2)' ipfw table mi_test create type cidr algo "cidr:hash masks=/30,/64" ipfw table mi_test add 10.0.0.8/30 ipfw table mi_test add 2a02:6b8:b010::1/64 25 # ipfw table si add 1.1.1.1/32 1111 2.2.2.2/32 2222 added: 1.1.1.1/32 1111 added: 2.2.2.2/32 2222 # ipfw table si add 2.2.2.2/32 2200 4.4.4.4/32 4444 exists: 2.2.2.2/32 2200 added: 4.4.4.4/32 4444 ipfw: Adding record failed: record already exists ^^^^^ Returns error but keeps inserted items # ipfw table si list +++ table(si), set(0) +++ 1.1.1.1/32 1111 2.2.2.2/32 2222 4.4.4.4/32 4444 # ipfw table si atomic add 3.3.3.3/32 3333 4.4.4.4/32 4400 5.5.5.5/32 5555 added(reverted): 3.3.3.3/32 3333 exists: 4.4.4.4/32 4400 ignored: 5.5.5.5/32 5555 ipfw: Adding record failed: record already exists ^^^^^ Returns error and reverts added records Performance changes: * Main ipfw lock was converted to rmlock * Rule counters were separated from rule itself and made per-cpu. * Radix table entries fits into 128 bytes * struct ip_fw is now more compact so more rules will fit into 64 bytes * interface tables uses array of existing ifindexes for faster match ABI changes: All functionality supported by old ipfw(8) remains functional. Old & new binaries can work together with the following restrictions: * Tables named other than ^\d+$ are shown as table(65535) in ruleset in old binaries * I'm a bit unsure about "lookup src-port|dst-port N" case, something may be broken here. Anyway, this can be fixed for MFC Internal changes:. Changing table ids to numbers resulted in format modification for most sockopt codes. Old sopt format was compact, but very hard to extend (no versioning, inability to add more opcodes), so * All relevant opcodes were converted to TLV-based versioned IP_FW3-based codes. * The remaining opcodes were also converted to be able to eliminate all older opcodes at once * All IP_FW3 handlers uses special API instead of calling sooptcopy* directly to ease adding another communication methods * struct ip_fw is now different for kernel and userland * tablearg value has been changed to 0 to ease future extensions * table "values" are now indexes in special value array which holds extended data for given index * Batched add/delete has been added to tables code * Most changes has been done to permit batched rule addition. * interface tracking API has been added (started on demand) to permit effective interface tables operations * O(1) skipto cache, currently turned off by default at compile-time (eats 512K). * Several steps has been made towards making libipfw: * most of new functions were separated into "parse/prepare/show and actuall-do-stuff" pieces (already merged). * there are separate functions for parsing text string into "struct ip_fw" and printing "struct ip_fw" to supplied buffer (already merged). * Probably some more less significant/forgotten features