From owner-freebsd-ipfw@freebsd.org Sun Oct 21 15:19:48 2018 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6835DFF6530 for ; Sun, 21 Oct 2018 15:19:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 05E0D92533 for ; Sun, 21 Oct 2018 15:19:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id BBF86FF652C; Sun, 21 Oct 2018 15:19:47 +0000 (UTC) Delivered-To: ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AACA9FF652B for ; Sun, 21 Oct 2018 15:19:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 380A492531 for ; Sun, 21 Oct 2018 15:19:47 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 7D10725512 for ; Sun, 21 Oct 2018 15:19:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9LFJkiw031275 for ; Sun, 21 Oct 2018 15:19:46 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9LFJkAq031268 for ipfw@FreeBSD.org; Sun, 21 Oct 2018 15:19:46 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 232465] ipfw -c is not working Date: Sun, 21 Oct 2018 15:19:46 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: bin X-Bugzilla-Version: 11.2-RELEASE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: ae@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: ipfw@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2018 15:19:48 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D232465 Andrey V. Elsukov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ae@FreeBSD.org Assignee|bugs@FreeBSD.org |ipfw@FreeBSD.org --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-ipfw@freebsd.org Sun Oct 21 21:00:47 2018 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7C9CF10088AB for ; Sun, 21 Oct 2018 21:00:47 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 1BA08779EF for ; Sun, 21 Oct 2018 21:00:47 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: by mailman.ysv.freebsd.org (Postfix) id D2EAD10088A5; Sun, 21 Oct 2018 21:00:46 +0000 (UTC) Delivered-To: ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C182C10088A2 for ; Sun, 21 Oct 2018 21:00:46 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 64B63779E9 for ; Sun, 21 Oct 2018 21:00:46 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id AE4634BE for ; Sun, 21 Oct 2018 21:00:45 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9LL0jZW087534 for ; Sun, 21 Oct 2018 21:00:45 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9LL0j8h087526 for ipfw@FreeBSD.org; Sun, 21 Oct 2018 21:00:45 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201810212100.w9LL0j8h087526@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: ipfw@FreeBSD.org Subject: Problem reports for ipfw@FreeBSD.org that need special attention Date: Sun, 21 Oct 2018 21:00:45 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Oct 2018 21:00:47 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 215875 | [ipfw] ipfw lookup tables do not support mbuf_tag 1 problems total for which you should take action. From owner-freebsd-ipfw@freebsd.org Tue Oct 23 11:12:33 2018 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EEC0C1075718 for ; Tue, 23 Oct 2018 11:12:32 +0000 (UTC) (envelope-from ole@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 95184765D3 for ; Tue, 23 Oct 2018 11:12:32 +0000 (UTC) (envelope-from ole@free.de) Received: from bard (x4db6ada2.dyn.telefonica.de [77.182.173.162]) by smtp.free.de (Postfix) with ESMTPSA id 3515AC396; Tue, 23 Oct 2018 13:12:24 +0200 (CEST) Date: Tue, 23 Oct 2018 13:12:20 +0200 From: Ole To: "Andrey V. Elsukov" Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw managing rules - best practice? Message-ID: <20181023131220.20c700ba.ole@free.de> In-Reply-To: <67544958-07fe-7ff4-b5d2-88bf85324061@yandex.ru> References: <20180905112847.54287198.ole@free.de> <67544958-07fe-7ff4-b5d2-88bf85324061@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/AZLnQq=7P8FM2.ktGUWtlVf"; protocol="application/pgp-signature" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 11:12:33 -0000 --Sig_/AZLnQq=7P8FM2.ktGUWtlVf Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Wed, 5 Sep 2018 18:33:58 +0300 - "Andrey V. Elsukov" : > On 05.09.2018 12:28, Ole wrote: > > I understand, that this connections get broken because the dynamic=20 > > rules get flushed with the `ipfw -q -f flush` command. But > > commenting this command out results in a continuously growing rules > > table. > >=20 > > With the `ipfw -d list` command I can see the dynamic rules.=20 > > Is there a way to flush the rules but not the dynamic ones? > > Or to add them again after flush? =20 >=20 > There is net.inet.ip.fw.dyn_keep_states sysctl variable. It allows to > keep dynamic state when parent rule is deleted. But you need to use > default_to_accept firewall to make it working. > I plan to reimplement this feature to be more useful and work with any > rules, and not only with "allow" rules. Ah, thank you very much. This is exactly what I was searching for. I deployed it to some machines and it is working well. One Question: I have lots of hostname dependend rules in lots of jails. Do you think it is OK to reload the ruleset every 5 min by cron to re-resolv the hostnames? regards Ole --Sig_/AZLnQq=7P8FM2.ktGUWtlVf Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJbzwIXAAoJECWWkUao5JRQn3kP/RZOizq10qY89QMq1TOxQKI0 jhhxNJkCyJLSEXSOzlpqb3mmLT9fyrPCznlND/c6PPg61ageayiJaAUUzmPiY+0G i+2lFxNBGpCh53F1Z/3FQd8f3SlKDVkhaq+zZxvUG4NO0zlGsTcLfKGxYXCyYMsX drcYmDacdTSabBUZKpSLGHS3aIbvxa0vOmNhZdOaMV5ZIy9CAU0qgGFxFTpKtBQ3 U+8dp/t7bo5ikW4pab3qs90yzwXRccDDqDX5DYQAofWkuByoWa/r4bD5bt6NEK76 o9yUOsqJvl1nAXs1vT6zdL8K0ijXLsDWbLpOaO0BfZQU3T30BgH+YDQD/2uojoFw DHjo17jUf7MIlhvikS7siYxRjiG7duYf6D6K9KRJRVU72S5T8/MmKzGFNmEhB9KV TLGcT3BvgrwqUszdcv+gd8YFx5mCTxa8vOWDgVhdYG6eOLMxoWGJUpm13ttieb2X 93zcMQwO0zB/6A4bxbal40w8HuM0dZAq38rHR+sFctCdJ322dX52Tf0qA3xbbaWS g/m/fmjXbNHPoeMSkBc8W7NNOUaroNYLxZeiffRxhq8AFJwSm65Runz+SsiXuCIX 0rKpTZ6U6A+nnHeqFl+7izGh1PFI6t/WhWPC9iO/RuaPLwmB4fWxC7x+B37V5kVc 0JjoIlxq6tsFD2Qfcwp2 =D0w3 -----END PGP SIGNATURE----- --Sig_/AZLnQq=7P8FM2.ktGUWtlVf-- From owner-freebsd-ipfw@freebsd.org Tue Oct 23 15:31:05 2018 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 702AFFE9CF9 for ; Tue, 23 Oct 2018 15:31:05 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (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 CD73181E89 for ; Tue, 23 Oct 2018 15:31:04 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w9NFUsxT021215; Tue, 23 Oct 2018 08:30:54 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w9NFUroH021214; Tue, 23 Oct 2018 08:30:53 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201810231530.w9NFUroH021214@pdx.rh.CN85.dnsmgr.net> Subject: Re: ipfw managing rules - best practice? In-Reply-To: <20181023131220.20c700ba.ole@free.de> To: Ole Date: Tue, 23 Oct 2018 08:30:53 -0700 (PDT) CC: "Andrey V. Elsukov" , freebsd-ipfw@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Oct 2018 15:31:05 -0000 > Wed, 5 Sep 2018 18:33:58 +0300 - "Andrey V. Elsukov" > : > > > On 05.09.2018 12:28, Ole wrote: > > > I understand, that this connections get broken because the dynamic > > > rules get flushed with the `ipfw -q -f flush` command. But > > > commenting this command out results in a continuously growing rules > > > table. > > > > > > With the `ipfw -d list` command I can see the dynamic rules. > > > Is there a way to flush the rules but not the dynamic ones? > > > Or to add them again after flush? > > > > There is net.inet.ip.fw.dyn_keep_states sysctl variable. It allows to > > keep dynamic state when parent rule is deleted. But you need to use > > default_to_accept firewall to make it working. > > I plan to reimplement this feature to be more useful and work with any > > rules, and not only with "allow" rules. > > Ah, thank you very much. This is exactly what I was searching for. I > deployed it to some machines and it is working well. > > One Question: I have lots of hostname dependend rules in lots of jails. > Do you think it is OK to reload the ruleset every 5 min by cron to > re-resolv the hostnames? Your milage may vary depending on what your doing, but here are some ideas. My prefered method for dealing with lots of IP/hostnames in ipfw rule sets is to place them all in different tables and then just flushing and rebuilding the tables rather than the whole rule set. I can think of using the value in the table to indicate what generation that IP belongs to and doing some fancier things that would do the lookups and add them to the table as generation n++, then when finished iterate over the table and delete all generation n IP's, then bump the generation number which can be stored in the table on 0.0.0.0/32 (not default, but literaly the all 0's address, or some other magic token. I have done that type of thing from a C program for other usses, not for name resolving. -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-ipfw@freebsd.org Wed Oct 24 16:23:13 2018 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6FF7FFFB5B1 for ; Wed, 24 Oct 2018 16:23:13 +0000 (UTC) (envelope-from ole@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 00FE06C64F for ; Wed, 24 Oct 2018 16:23:12 +0000 (UTC) (envelope-from ole@free.de) Received: from bard (x4db6f5cc.dyn.telefonica.de [77.182.245.204]) by smtp.free.de (Postfix) with ESMTPSA id 73155C617; Wed, 24 Oct 2018 18:23:05 +0200 (CEST) Date: Wed, 24 Oct 2018 18:22:52 +0200 From: Ole To: "Andrey V. Elsukov" Cc: freebsd-ipfw@freebsd.org Subject: Re: ipfw managing rules - best practice? Message-ID: <20181024182252.49ee516b.ole@free.de> In-Reply-To: <20181023131220.20c700ba.ole@free.de> References: <20180905112847.54287198.ole@free.de> <67544958-07fe-7ff4-b5d2-88bf85324061@yandex.ru> <20181023131220.20c700ba.ole@free.de> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/RFn0HK2H0eDs9BF2sS_z3nU"; protocol="application/pgp-signature" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 16:23:13 -0000 --Sig_/RFn0HK2H0eDs9BF2sS_z3nU Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Tue, 23 Oct 2018 13:12:20 +0200 - Ole : > Wed, 5 Sep 2018 18:33:58 +0300 - "Andrey V. Elsukov" > : >=20 > > On 05.09.2018 12:28, Ole wrote: > > > I understand, that this connections get broken because the > > > dynamic rules get flushed with the `ipfw -q -f flush` command. But > > > commenting this command out results in a continuously growing > > > rules table. > > >=20 > > > With the `ipfw -d list` command I can see the dynamic rules.=20 > > > Is there a way to flush the rules but not the dynamic ones? > > > Or to add them again after flush? =20 > >=20 > > There is net.inet.ip.fw.dyn_keep_states sysctl variable. It allows > > to keep dynamic state when parent rule is deleted. But you need to > > use default_to_accept firewall to make it working. > > I plan to reimplement this feature to be more useful and work with > > any rules, and not only with "allow" rules. >=20 > Ah, thank you very much. This is exactly what I was searching for. I > deployed it to some machines and it is working well. OK, it is not working. I tested it only on a host system. It was working. When I deployed the=20 ipfw script to the jails I missed that 'ipfw -q -f flush' was commented out. So what happens inside the Jail: Host: # sysctl net.inet.ip.fw net.inet.ip.fw.dyn_keep_states: 1 net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.dyn_parent_max: 4096 net.inet.ip.fw.dyn_max: 16384 net.inet.ip.fw.dyn_buckets: 8192 net.inet.ip.fw.curr_max_length: 0 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_parent_count: 0 net.inet.ip.fw.dyn_count: 0 net.inet.ip.fw.enable: 1 net.inet.ip.fw.static_count: 12 net.inet.ip.fw.default_to_accept: 1 net.inet.ip.fw.tables_sets: 0 net.inet.ip.fw.tables_max: 128 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 0 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.one_pass: 1 Jail: # sysctl net.inet.ip.fw net.inet.ip.fw.dyn_keep_states: 1 net.inet.ip.fw.dyn_keepalive: 1 net.inet.ip.fw.dyn_short_lifetime: 5 net.inet.ip.fw.dyn_udp_lifetime: 10 net.inet.ip.fw.dyn_rst_lifetime: 1 net.inet.ip.fw.dyn_fin_lifetime: 1 net.inet.ip.fw.dyn_syn_lifetime: 20 net.inet.ip.fw.dyn_ack_lifetime: 300 net.inet.ip.fw.dyn_parent_max: 4096 net.inet.ip.fw.dyn_max: 16384 net.inet.ip.fw.dyn_buckets: 8192 net.inet.ip.fw.curr_max_length: 1 net.inet.ip.fw.curr_dyn_buckets: 256 net.inet.ip.fw.dyn_parent_count: 0 net.inet.ip.fw.dyn_count: 3 net.inet.ip.fw.enable: 1 net.inet.ip.fw.static_count: 41 net.inet.ip.fw.default_to_accept: 1 net.inet.ip.fw.tables_sets: 0 net.inet.ip.fw.tables_max: 128 net.inet.ip.fw.default_rule: 65535 net.inet.ip.fw.verbose_limit: 0 net.inet.ip.fw.verbose: 0 net.inet.ip.fw.autoinc_step: 100 net.inet.ip.fw.one_pass: 1 # ipfw -d list=20 (...) 01510 allow tcp from any to xx.xx.xx.xx 6514 out via epair0b setup keep-sta= te :default (...) ## Dynamic rules (1 152): 01510 STATE tcp yy.yy.yy.yy 54451 <-> xx.xx.xx.xx 6514 :default # ipfw -q flush # ipfw -d list 65535 allow ip from any to any ## Dynamic rules (2 288): Segmentation fault (core dumped) It not always ends up with a segmnetation fault. Sometimes there are 'empty' rules (blank lines): ## Dynamic rules (7 968): 01510 STATE tcp xx.xx.xx.xx 48347 <-> xx.xx.xx.xx 6514 :default 01111 STATE udp xx.xx.xx.xx 19693 <-> xx.xx.xx.xx :default 01111 STATE udp xx.xx.xx.xx 45532 <-> xx.xx.xx.xx :default ---End-of-output I'm using FreeBSD 11.2 with vnet Jails. regards Ole --Sig_/RFn0HK2H0eDs9BF2sS_z3nU Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJb0JxoAAoJECWWkUao5JRQhgwP/Anz+9wmvKH+/2U3E91WYn8a U86woHOK+UAkEX7qhTMyW+Yh1du4tAkVZknDhytlwJ+StCAndsTU/V72rPS2AoH9 8OkavQX10UImc26n6WycKK8OlrmaCDcleYEivMXAZXbR3VrtJMfN0iJ1yO5JXrV1 5/bk3tzeH4XoueM+RrlaoBB+LdbduJDsDrRASCdMCjksgAQEDUdtZEjqEbTWaamu YXk28sOgvwpBJF/4wxnhTLAwM4ZwvUybE9aiuDLh/FHZ0sYVqoIfNhAe1TM1lbex 1Bi+BSIgOuooZVXQdS++EEVfKjkpvtNJVjQdWRjGeooQzFuS/lfKYOlkhGyNGwgu 28gk3D3RHHejlCNqSw2dW9zMaVZiU7b9UY+NnqkTk8PO5wjjJLxuGDor+yAAeV8V ZXxpgqFUc7utvOZoR4IDXSU0McuEsI0uWe/6BeXdqXWBx0sf+QGfeYqbTCDOGK85 0Bv6Qagx5fsigeL9stT3J4F/7t1b2xbtRTT/SyFoyqJHH1wPebNgLxAHSbDdKsm8 eAjm9nesv7as7bjEN2RaX0+1gH+7N5MBla4dMJMmtSawbzwyco07b3qkCzRJ3Rll Mum7qlXPrCKHK3EnCweflpliJyy8L5sD7uCbHOxQvycx8dyKvXia5W7BolgtFlAS 9/liiULK2ICgIbz4G2Me =K+wU -----END PGP SIGNATURE----- --Sig_/RFn0HK2H0eDs9BF2sS_z3nU-- From owner-freebsd-ipfw@freebsd.org Wed Oct 24 18:44:12 2018 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9765F10366DC for ; Wed, 24 Oct 2018 18:44:12 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward103p.mail.yandex.net (forward103p.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "forwards.mail.yandex.net", Issuer "Yandex CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F310874E07 for ; Wed, 24 Oct 2018 18:44:11 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback15o.mail.yandex.net (mxback15o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::66]) by forward103p.mail.yandex.net (Yandex) with ESMTP id C10792183FEA; Wed, 24 Oct 2018 21:43:47 +0300 (MSK) Received: from smtp3p.mail.yandex.net (smtp3p.mail.yandex.net [2a02:6b8:0:1472:2741:0:8b6:8]) by mxback15o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id 8KcNkyRQz0-hlG0FBrd; Wed, 24 Oct 2018 21:43:47 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1540406627; bh=KVK0DICFBhmuRt9LmPMyyYV+kRpZFN+xjipvsUGymFA=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=LVaAS4hCv7alUiaFKEV4i0hxrFKF/zboe62Q3e+ngdZumEzUWKneEBFdmEb6KF+/C H7sSZ5gyttyIULCl1kYsUOD61SrB3auPpdTnnQo0yfXJbYQ7gSpOH/kp0u5z4zn7JF 9iIOS/B9Tjb4DdY4E5KQO2hG8E3/qGYMHBCJuqrM= Received: by smtp3p.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id 710xxvbPLD-hkn4LvCr; Wed, 24 Oct 2018 21:43:46 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1540406626; bh=KVK0DICFBhmuRt9LmPMyyYV+kRpZFN+xjipvsUGymFA=; h=Subject:To:Cc:References:From:Message-ID:Date:In-Reply-To; b=f5pq8ttxj+oOHGLaa2Qjt5nsGLSngP2EuNiyr1t6hRe4AhD3bYMIfOc8K7zUIfHlM FNSKpF63PwIwAwgBjHc/kZbk5fY7M8Cfp3Vn8AxQeM9BFlW+mRxCPYffYcT4P4ZVZ2 nb2dsFR2CBURgoTqfsE18PoX7IlzfuV5GNiRQv/E= Authentication-Results: smtp3p.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: ipfw managing rules - best practice? To: Ole Cc: freebsd-ipfw@freebsd.org References: <20180905112847.54287198.ole@free.de> <67544958-07fe-7ff4-b5d2-88bf85324061@yandex.ru> <20181023131220.20c700ba.ole@free.de> <20181024182252.49ee516b.ole@free.de> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= xsBNBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAHNIkFuZHJleSBWLiBFbHN1a292IDxhZUBmcmVlYnNkLm9yZz7CwHsEEwECACUCGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheABQJMB/ruAhkBAAoJEAHF6gQQyKF6MLwH/3Ri/TZl9uo0 SepYWXOnxL6EaDVXDA+dLb1eLKC4PRBBjX29ttQ0KaWapiE6y5/AfzOPmRtHLrHYHjd/aiHX GMLHcYRXD+5GvdkK8iMALrZ28X0JXyuuZa8rAxWIWmCbYHNSBy2unqWgTI04Erodk90IALgM 9JeHN9sFqTM6zalrMnTzlcmel4kcjT3lyYw3vOKgoYLtsLhKZSbJoVVVlvRlGBpHFJI5AoYJ SyfXoN0rcX6k9X7Isp2K50YjqxV4v78xluh1puhwZyC0p8IShPrmrp9Oy9JkMX90o6UAXdGU KfdExJuGJfUZOFBTtNIMNIAKfMTjhpRhxONIr0emxxDOwE0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAcLAXwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: <6bb037c2-643d-151b-cb34-f78c97f241d4@yandex.ru> Date: Wed, 24 Oct 2018 21:42:00 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181024182252.49ee516b.ole@free.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xTkE80mW3ce0SYYNyUoFX9oEw4CeS3ICF" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Oct 2018 18:44:12 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xTkE80mW3ce0SYYNyUoFX9oEw4CeS3ICF Content-Type: multipart/mixed; boundary="LBxTwxfGlYY1I14vTXF3iQdZhxqGK7ymm"; protected-headers="v1" From: "Andrey V. Elsukov" To: Ole Cc: freebsd-ipfw@freebsd.org Message-ID: <6bb037c2-643d-151b-cb34-f78c97f241d4@yandex.ru> Subject: Re: ipfw managing rules - best practice? References: <20180905112847.54287198.ole@free.de> <67544958-07fe-7ff4-b5d2-88bf85324061@yandex.ru> <20181023131220.20c700ba.ole@free.de> <20181024182252.49ee516b.ole@free.de> In-Reply-To: <20181024182252.49ee516b.ole@free.de> --LBxTwxfGlYY1I14vTXF3iQdZhxqGK7ymm Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 24.10.2018 19:22, Ole wrote: > # ipfw -d list=20 > (...) > 01510 allow tcp from any to xx.xx.xx.xx 6514 out via epair0b setup keep= -state :default > (...) > ## Dynamic rules (1 152): > 01510 STATE tcp yy.yy.yy.yy 54451 <-> xx.xx.xx.xx 6514 :default >=20 > # ipfw -q flush >=20 > # ipfw -d list > 65535 allow ip from any to any > ## Dynamic rules (2 288): > Segmentation fault (core dumped) This problem is related to named states, the kernel doesn't dump list of known states names, and this is the cause of SIGSEGV. I have the WIP patch https://people.freebsd.org/~ae/keep_states.diff It fixes this problem and also add support for all rule actions. Also it adds new -D flag, that allows to show only states and delete only states. I have tested it basically, but it probably needs some work related to "limit" dynamic states. So if you want to test some patches, you can try :) I tried to apply the patch and observed that stable/11 has a small difference in UMA code, so you need to use this patch: https://people.freebsd.org/~ae/keep_states11.diff Again, I did not yet teseted it widely, and on stable/11 did not tested at all. --=20 WBR, Andrey V. Elsukov --LBxTwxfGlYY1I14vTXF3iQdZhxqGK7ymm-- --xTkE80mW3ce0SYYNyUoFX9oEw4CeS3ICF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlvQvPgACgkQAcXqBBDI oXo2AQgAkpx86MReoTBlhDctC9KtqKZs2wQlQFZtL/IfGvbj/ZAv0oX2c4UADCJz 3I2OKQC9Lziem4MimZrsEjgbLpPbQ5H0EU5O1vJ0tsKJfRq14VeaHYEHTKPpUzjn WGrsWxd5luWov6VIPf60QUJnkdJk+7Q6mefao7M1OueD3ipnVMA8u6/YbPPf/nWc TKVnvxURftX547KhWR5zQ2WE5OO2ADyoWxjnP4qFrtkodO77w3yWtjqqCQpWBPhl jklxyooWbH/m+Hs7whp7URNweJCUDco+9X4oE7NG3VAWWZb/7GATrKdOaAgtBzXp 9HSB8AO+ExI5LGTPG0g8epujAc3lzg== =aHFV -----END PGP SIGNATURE----- --xTkE80mW3ce0SYYNyUoFX9oEw4CeS3ICF-- From owner-freebsd-ipfw@freebsd.org Thu Oct 25 08:18:38 2018 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 15369FFE0F8 for ; Thu, 25 Oct 2018 08:18:38 +0000 (UTC) (envelope-from guobin@xycar-dvr.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id AE6E2767C7 for ; Thu, 25 Oct 2018 08:18:37 +0000 (UTC) (envelope-from guobin@xycar-dvr.com) Received: by mailman.ysv.freebsd.org (Postfix) id 73A44FFE0F7; Thu, 25 Oct 2018 08:18:37 +0000 (UTC) Delivered-To: ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 39EE7FFE0F6 for ; Thu, 25 Oct 2018 08:18:37 +0000 (UTC) (envelope-from guobin@xycar-dvr.com) Received: from m97116.mail.qiye.163.com (m97116.mail.qiye.163.com [220.181.97.116]) by mx1.freebsd.org (Postfix) with ESMTP id 09B00767C6 for ; Thu, 25 Oct 2018 08:18:33 +0000 (UTC) (envelope-from guobin@xycar-dvr.com) Received: from guobin$xycar-dvr.com ( [119.123.132.125] ) by ajax-webmail-wmsvr12 (Coremail) ; Thu, 25 Oct 2018 16:17:39 +0800 (CST) X-Originating-IP: [119.123.132.125] Date: Thu, 25 Oct 2018 16:17:39 +0800 (CST) From: wendygao To: ipfw@freebsd.org Subject: The Great Profit RC Bait Boat from Shenzhen X-Priority: 3 X-Mailer: Coremail Webmail Server Version SP_ntes V3.5 build 20150911(74783.7961) Copyright (c) 2002-2018 www.mailtech.cn 163-hosting MIME-Version: 1.0 Message-ID: <2f8853ee.cdfa.166aa4ceb54.Coremail.guobin@xycar-dvr.com> X-CM-TRANSID: dOCowACXlXkkfNFb_ZGzAA--.8364W X-CM-SenderInfo: xjxrux3q605uddunv43uof0z/1tbigwPqE1sflatMRwACsK X-Coremail-Antispam: 1U5529EdanIXcx71UUUUU7vcSsGvfC2KfnxnUU== Content-Type: text/plain; charset=GBK Content-Transfer-Encoding: base64 X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 08:18:38 -0000 SGVsbG8sIFNpcgoKCkhvcGUgdGhpcyBlbWFpbCBjb3VsZCBmaW5kIHlvdSB3ZWxsLiBXZSBhcmUg dGhlIG9yaWdpbmFsIGZhY3RvcnkgZnJvbSBTaGVuemhlbiwgSSBhbSBoZXJlIGludHJvZHVjaW5n IG91ciBSQyBiYWl0IGJvYXRzIGZvciB5b3VyIHJlZmVyZW5jZS4KCgpUaGUgaW5mb3JtYXRpb24g b2YgdGhlIGJhaXQgYm9hdCBhcyBmb2xsb3dzOgoxLkQwNShncmVlbiBjb2xvcik6IFJDIGRpc3Rh bmNlIGlzIGFib3V0IDUwME0sIDMgYmFpdCBiaW5zLCBsb2FkIGFib3V0IDNrZ3MgYmFpdDsgYm9h dCBzaXplOkw1NSpXMjcqSDEwY20sIHR3byBicnVzaCBtb3RvcnMuCjIuRDA2KGJsYWNrIGNvbG9y KTogUkMgZGlzdGFuY2UgaXMgYWJvdXQgNDAwTSwgMiBiYWl0IGJpbnMsIGxvYWQgYWJvdXQgMmtn cyBiYWl0LiBib2F0IHNpemU6TDUzKlczNypIMjZjbSwgdHdvIGJydXNoIG1vdG9ycy4KCgpQbGVh c2Uga2luZGx5IGNvbnRhY3QgbWUgZnJlZWx5IGlmIHlvdSB3YW50IHRvIGtub3cgbW9yZSBpbmZv cm1hdGlvbiBhYm91dCB0aGVtLgoKCldhaXRpbmcgZm9yIHlvdXIga2luZCByZXBseSEKCgoKCgot LQoKV2VuZHkgRm9yZWlnbiBTYWxlcwpndW9iaW5AeHljYXItZHZyLmNvbQpTaGVuemhlbiBDaXR5 IEd1b2JpbiBUZWNobm9sb2d5IENvLiwgTHRkCkFkZDo0dGggRmxvb3IsIElEVCBCdWlsZGluZywg Q2hlbnRpYW4gSW5kdXN0cmlhbCwgU2hlbnpoZW4KaHR0cHM6Ly9zemdvYi5lbi5hbGliYWJhLmNv bS8KQ2VsbDo4Ni0xODg5ODU5NDA1OQ== From owner-freebsd-ipfw@freebsd.org Thu Oct 25 09:09:24 2018 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3E361008294 for ; Thu, 25 Oct 2018 09:09:24 +0000 (UTC) (envelope-from ole@free.de) Received: from smtp.free.de (smtp.free.de [91.204.6.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3DC9C78306 for ; Thu, 25 Oct 2018 09:09:24 +0000 (UTC) (envelope-from ole@free.de) Received: from bard (x4db68219.dyn.telefonica.de [77.182.130.25]) by smtp.free.de (Postfix) with ESMTPSA id BD563C787 for ; Thu, 25 Oct 2018 11:09:22 +0200 (CEST) Date: Thu, 25 Oct 2018 11:09:19 +0200 From: Ole To: freebsd-ipfw@freebsd.org Subject: net.inet.ip.fw.dyn_keep_states (was: ipfw managing rules - best practice?) Message-ID: <20181025110919.61379c13.ole@free.de> In-Reply-To: <6bb037c2-643d-151b-cb34-f78c97f241d4@yandex.ru> References: <20180905112847.54287198.ole@free.de> <67544958-07fe-7ff4-b5d2-88bf85324061@yandex.ru> <20181023131220.20c700ba.ole@free.de> <20181024182252.49ee516b.ole@free.de> <6bb037c2-643d-151b-cb34-f78c97f241d4@yandex.ru> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/irWQrmpBiHmBWoM5Lm84yzv"; protocol="application/pgp-signature" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 09:09:24 -0000 --Sig_/irWQrmpBiHmBWoM5Lm84yzv Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Wed, 24 Oct 2018 21:42:00 +0300 - "Andrey V. Elsukov" : > On 24.10.2018 19:22, Ole wrote: > > # ipfw -d list=20 > > (...) > > 01510 allow tcp from any to xx.xx.xx.xx 6514 out via epair0b setup > > keep-state :default (...) > > ## Dynamic rules (1 152): > > 01510 STATE tcp yy.yy.yy.yy 54451 <-> xx.xx.xx.xx 6514 :default > >=20 > > # ipfw -q flush > >=20 > > # ipfw -d list > > 65535 allow ip from any to any > > ## Dynamic rules (2 288): > > Segmentation fault (core dumped) > This problem is related to named states, the kernel doesn't dump list > of known states names, and this is the cause of SIGSEGV. Ok, I got a little bit confused. I was searching for a workaround. So I changed the rules from $cmd 01610 allow tcp from vpn.example.org to me 22 in via $pif setup limit src-addr 50 to $cmd 01610 allow tcp from vpn.example.org to me 22 in via $pif keep-state In my understanding of the IPFW(8) the 'setup' command puts new entries to the dynamic table if there=20 " Matches TCP packets that have the SYN bit set but no ACK bit."=20 So if there new TCP connection establishment. That is the reason why connections get broken after reload. (inkluding flush) My idea was just to use 'keep-state'. Because this also puts new entries to the dynamic table. But for every package. " Upon a match, the firewall will create a dynamic rule, whose default behaviour is to match bidirectional traffic between source and destination IP/port using the same protocol." But after reload. The dynamic rules are gone, and they will not get updated. TCP connections get broken. Intresting: if I set 'sysctl net.inet.ip.fw.dyn_keep_states=3D1' the firewall behaves like I expected above. But not because dynamic rules got recreated. The don't get flushed: # ipfw -da list (...) 01610 223 26457 (282s) STATE tcp xx.xx.xx.xx 36955 <-> xx.xx.xx.xx 22 :de= fault (...) # service ipfw restart Firewall rules loaded. # ipfw -da list (...) 01610 223 26457 (278s) STATE tcp xx.xx.xx.xx 36955 <-> xx.xx.xx.xx 22 :de= fault (...) So do you think the bug is only related to 'setup' and not to 'keep-state' rules? Or is this just a coincidence?=20 Im reloading rules now for 1h each minute, and a ssh connection is still st= able. > I have the WIP patch https://people.freebsd.org/~ae/keep_states.diff > It fixes this problem and also add support for all rule actions. > Also it adds new -D flag, that allows to show only states and delete > only states. I have tested it basically, but it probably needs some > work related to "limit" dynamic states. > So if you want to test some patches, you can try :) > I tried to apply the patch and observed that stable/11 has a small > difference in UMA code, so you need to use this patch: > https://people.freebsd.org/~ae/keep_states11.diff >=20 > Again, I did not yet teseted it widely, and on stable/11 did not > tested at all. Great, thanks I will give it a try in a testing setup! regards Ole --Sig_/irWQrmpBiHmBWoM5Lm84yzv Content-Type: application/pgp-signature Content-Description: Digitale Signatur von OpenPGP -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJb0YhCAAoJECWWkUao5JRQybsP+QEwwEF4AtxggoBsIMYxYhYx 2opOdZZdWs7zRHPMEimBlh9DGlDjxEfTYaqKgQNyLynTVAxeFKYStb/PXSmu1jWG Wgm9DAVyofDE8iowTS0PJzoa5NGrcRy4fy7yOtS3FhdAv/MS51IuGlG9Ws9/Up/4 exqu3ZFaX2gbCQIL8lk5MNLcjVVMQWMURDCCYlOQsrqagUqhLRE0eliltNv34G0C 3IPUIDalDy8URAP6po4jn+4s+UsoEsBmLlgiAJ0ABxGvD5czP0Qg18ztZkzfFLPH teY8+vTPoA5xbX124oOdW5yPkejbZAs9D4RMN38ohmBN5Sc2VkNzPrMrDBdjNC2V uluTpbKxWV9sIF/xyz9f1eqoY9gTnsilBPR6BJdB/HgVF5GsXpJTayTY+v+GdAhm HtRrDpfwP0ZTGiOY7hGBSUyCVxG9eQwFP/U7Psp71TmcaywqJ4OQpG77lPejux3X XAf+bp7aDC1vFzujl/rkxsQmctJBDQZFISbWZ4gYIpy19L5WJyR6L7lD20/FfKe7 KofitrquVw4w6U+UzoSfIUIv/opYmjzFfWtuj7+1v45uNfV6bdgO9uK6yhjo5xZu DgcyZksXcR+nfwpl7tSdcE+xzeWd0YpkEGfgUWZfwnQJwB7xT8zpFXwp8foqQpAw TtXuNeM5rDJQv4D27Hxu =KM1g -----END PGP SIGNATURE----- --Sig_/irWQrmpBiHmBWoM5Lm84yzv-- From owner-freebsd-ipfw@freebsd.org Thu Oct 25 13:41:24 2018 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 014EE107696D for ; Thu, 25 Oct 2018 13:41:24 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward104j.mail.yandex.net (forward104j.mail.yandex.net [5.45.198.247]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 6766882DD9 for ; Thu, 25 Oct 2018 13:41:22 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback17o.mail.yandex.net (mxback17o.mail.yandex.net [IPv6:2a02:6b8:0:1a2d::68]) by forward104j.mail.yandex.net (Yandex) with ESMTP id 33E43580490; Thu, 25 Oct 2018 16:41:20 +0300 (MSK) Received: from smtp4j.mail.yandex.net (smtp4j.mail.yandex.net [2a02:6b8:0:1619::15:6]) by mxback17o.mail.yandex.net (nwsmtp/Yandex) with ESMTP id Z4mrJMABX6-fJsaMul6; Thu, 25 Oct 2018 16:41:20 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1540474880; bh=DX9wHYn6LM+T4vPKK3P5Un0z73edZqdMEiA4o720XTI=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=HRp9+793jfCykAk5sxmOyZvWIUU1ubDXGUxN1ZX8tnBfEhUU4bIQ61JevLVtlex79 o3cndm6B5sUpyWYADD4DwboQpGK6f+E3RHhGMliYg3sELQmhLGEx3MYe/avD1C02Ti fkuCyc8BqRi2Q0RrPPwJJka/Oz20UrVRwYn3TYOU= Received: by smtp4j.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id iXPtejDXUu-fJbSPQtg; Thu, 25 Oct 2018 16:41:19 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1540474879; bh=DX9wHYn6LM+T4vPKK3P5Un0z73edZqdMEiA4o720XTI=; h=Subject:To:References:From:Message-ID:Date:In-Reply-To; b=hsJqSwp+OmEqWN/gvVD01+V91AzxRTp7FuV87RNBe5BwX00cgHkqZ0jicFSKEuEx3 By2EzMyr2mlv+Mai1yUSYcI7yjKLi7UA2vkbkS4puqC3J5xMVz2kXiFdIwJVzZgvmJ 6aEpAsVnBKgoHFzput/sEwA+MTaCkxg/Ts6B8LmQ= Authentication-Results: smtp4j.mail.yandex.net; dkim=pass header.i=@yandex.ru Subject: Re: net.inet.ip.fw.dyn_keep_states (was: ipfw managing rules - best practice?) To: Ole , freebsd-ipfw@freebsd.org References: <20180905112847.54287198.ole@free.de> <67544958-07fe-7ff4-b5d2-88bf85324061@yandex.ru> <20181023131220.20c700ba.ole@free.de> <20181024182252.49ee516b.ole@free.de> <6bb037c2-643d-151b-cb34-f78c97f241d4@yandex.ru> <20181025110919.61379c13.ole@free.de> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= xsBNBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAHNIkFuZHJleSBWLiBFbHN1a292IDxhZUBmcmVlYnNkLm9yZz7CwHsEEwECACUCGwMGCwkI BwMCBhUIAgkKCwQWAgMBAh4BAheABQJMB/ruAhkBAAoJEAHF6gQQyKF6MLwH/3Ri/TZl9uo0 SepYWXOnxL6EaDVXDA+dLb1eLKC4PRBBjX29ttQ0KaWapiE6y5/AfzOPmRtHLrHYHjd/aiHX GMLHcYRXD+5GvdkK8iMALrZ28X0JXyuuZa8rAxWIWmCbYHNSBy2unqWgTI04Erodk90IALgM 9JeHN9sFqTM6zalrMnTzlcmel4kcjT3lyYw3vOKgoYLtsLhKZSbJoVVVlvRlGBpHFJI5AoYJ SyfXoN0rcX6k9X7Isp2K50YjqxV4v78xluh1puhwZyC0p8IShPrmrp9Oy9JkMX90o6UAXdGU KfdExJuGJfUZOFBTtNIMNIAKfMTjhpRhxONIr0emxxDOwE0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAcLAXwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: <846ae8ef-be8b-08a6-6c07-ef62f8cb1a4b@yandex.ru> Date: Thu, 25 Oct 2018 16:39:25 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20181025110919.61379c13.ole@free.de> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4PeinUYON8Ve6scFxaOZ04LVp0mHvjEJL" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Oct 2018 13:41:24 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4PeinUYON8Ve6scFxaOZ04LVp0mHvjEJL Content-Type: multipart/mixed; boundary="VXq8KOyCgu1cI1pao52b3RvrOyCtTi6tx"; protected-headers="v1" From: "Andrey V. Elsukov" To: Ole , freebsd-ipfw@freebsd.org Message-ID: <846ae8ef-be8b-08a6-6c07-ef62f8cb1a4b@yandex.ru> Subject: Re: net.inet.ip.fw.dyn_keep_states (was: ipfw managing rules - best practice?) References: <20180905112847.54287198.ole@free.de> <67544958-07fe-7ff4-b5d2-88bf85324061@yandex.ru> <20181023131220.20c700ba.ole@free.de> <20181024182252.49ee516b.ole@free.de> <6bb037c2-643d-151b-cb34-f78c97f241d4@yandex.ru> <20181025110919.61379c13.ole@free.de> In-Reply-To: <20181025110919.61379c13.ole@free.de> --VXq8KOyCgu1cI1pao52b3RvrOyCtTi6tx Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 25.10.2018 12:09, Ole wrote: > So do you think the bug is only related to 'setup' and not to 'keep-sta= te' > rules? Or is this just a coincidence?=20 > Im reloading rules now for 1h each minute, and a ssh connection is stil= l stable. Hi, I think you do not quite understand how it works :) Dynamic states do not work automagically. In general words, you have two types of firewall rules - static and dynamic. Static rules are kept in an array and checked by firewall until some action will be applied, that will finish the search. Dynamic rules have special opcodes, that initiate the search in dynamic states. And if a packet doesn't have a match in these dynamic states, new dynamic state will be created for this packet. If some state matches a packet, then corresponding action will be applied for this packet. This is why usually "check-state" rule added to the beginning of rules. A packet will be checked first for match in dynamic states, and only then it will be checked by static rules. So, when you have many rules and states, doing `ipfw flush` will delete all static rules, but depending from keep_states sysctl variable, dynamic states can be kept or deleted. So, if you will do `ipfw -q flush` and do not add new dynamic rule, all dynamic states will expire after some time and will be deleted (regardless of the fact you have keep_states=3D1). But, when you are doing `flush` and then reload new rules, that have some dynamic rules (those that have "keep-state" or "limit" opcodes), this means that new rules will initiate the search in dynamic states, and for existing connection the state will be updated and because of this, the connection is still work. --=20 WBR, Andrey V. Elsukov --VXq8KOyCgu1cI1pao52b3RvrOyCtTi6tx-- --4PeinUYON8Ve6scFxaOZ04LVp0mHvjEJL Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAlvRx40ACgkQAcXqBBDI oXrnIwgAsTdExP4fylJ6N8N8SOpcNEIHFz2rDJdl9MgdeJ6Y4LBOVWdemYtUy06f VMVT3ZrZs8qohdJFdPacLyYL6bmUC22kqKaajTE/cprC7fiqfSzznnLcDiLhELps Zj161TTrVawUlc0/SiuEPhx5K52yv7/+LAj4HkrClXBNdwz0SvI6vXskkXaEOnn2 VJOeUkHcZduiS+VIgoQMCZN3x9NV05uFJfedmZMIvBPV53h/efXu3pj0t92b3ktV ipOleE8md9d7PhLmhgUFVlN4V0hulRce9lfrsi9dPSXQY9m1SjLO2QCwiTg7Gdv6 1j7yB4HOXUiV6B9Jm+SeXAiEcD7MjQ== =U4fi -----END PGP SIGNATURE----- --4PeinUYON8Ve6scFxaOZ04LVp0mHvjEJL-- From owner-freebsd-ipfw@freebsd.org Fri Oct 26 19:06:36 2018 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D8E78108600E for ; Fri, 26 Oct 2018 19:06:36 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from mail.otcnet.ru (mail.otcnet.ru [194.190.78.3]) by mx1.freebsd.org (Postfix) with ESMTP id 6FBC883CFF for ; Fri, 26 Oct 2018 19:06:35 +0000 (UTC) (envelope-from vit@otcnet.ru) Received: from Victors-MacBook-Air-2.local (unknown [195.91.148.145]) by mail.otcnet.ru (Postfix) with ESMTPSA id 9AF9D596762 for ; Fri, 26 Oct 2018 22:06:26 +0300 (MSK) To: freebsd-ipfw@freebsd.org From: Victor Gamov Subject: ipfw on vlans Organization: OTCnet Message-ID: <72880845-75ed-f2fa-272e-5fdfb3746e9e@otcnet.ru> Date: Fri, 26 Oct 2018 22:06:25 +0300 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Oct 2018 19:06:37 -0000 Hi All I have some misunderstood while configuring ipfw on VLAN-only interfaces My net look like following: -- network switch Juniper EX-2200 with port configured as follows: ge-0/0/12 { unit 0 { family ethernet-switching { port-mode trunk; vlan { members [ vlan1201 vlan1202 vlan202 ]; } } } } vlan1201 { vlan-id 1201 } -- FreeBSD 11.1-STABLE (r328066) connected to switch. vlan1201 on FreeBSD configured as: vlan1201: flags=8943 metric 0 mtu 1500 options=200001 ether 00:1b:21:bc:a8:0a inet 10.200.200.161 netmask 0xfffffff0 broadcast 10.200.200.175 nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active vlan: 1201 vlanpcp: 0 parent interface: igb2 groups: vlan -- igb2 configured as igb2: flags=8943 metric 0 mtu 1500 options=6403bb ether 00:1b:21:bc:a8:0a hwaddr 00:1b:21:bc:a8:0a nd6 options=29 media: Ethernet autoselect (1000baseT ) status: active I need to filter multicast received via vlan1201 and add following rule: 20000 allow udp from any to 239.20.2.1 in via vlan1201 30000 deny ip from any to any via vlan1201 65000 deny ip from any to any But no packets received by 20000 and I need to add: 15000 allow ip from any to any via igb2 Here is my misunderstood (or misconfiguration?): why I need "allow via igb2" -- I receive IP traffic via VLANs only? And why my test ipfw rules log something like Deny P:103 172.16.69.5 224.0.0.13 in via igb2 while I haven't traffic on pure igb2 but on VLANs only. Thanks for any explanations. -- CU Victor Gamov From owner-freebsd-ipfw@freebsd.org Sat Oct 27 07:48:46 2018 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3F64C10DE26C for ; Sat, 27 Oct 2018 07:48:46 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CFF51833E3 for ; Sat, 27 Oct 2018 07:48:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9589510DE26B; Sat, 27 Oct 2018 07:48:45 +0000 (UTC) Delivered-To: ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 849A210DE26A for ; Sat, 27 Oct 2018 07:48:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DBB2833E2 for ; Sat, 27 Oct 2018 07:48:45 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 5E470C407 for ; Sat, 27 Oct 2018 07:48:44 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9R7micr026487 for ; Sat, 27 Oct 2018 07:48:44 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9R7mitC026486 for ipfw@FreeBSD.org; Sat, 27 Oct 2018 07:48:44 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 213452] [patch] [ipfw] add support for ipfw ngtee/netgraph actions at layer-2 Date: Sat, 27 Oct 2018 07:48:44 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: eugen@freebsd.org X-Bugzilla-Status: In Progress X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 07:48:46 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213452 Eugene Grosbein changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Open |In Progress --=20 You are receiving this mail because: You are on the CC list for the bug.= From owner-freebsd-ipfw@freebsd.org Sat Oct 27 07:32:50 2018 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6A37310DD912 for ; Sat, 27 Oct 2018 07:32:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 0790B82BFF for ; Sat, 27 Oct 2018 07:32:50 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id C103310DD911; Sat, 27 Oct 2018 07:32:49 +0000 (UTC) Delivered-To: ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AFCF710DD910 for ; Sat, 27 Oct 2018 07:32:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4F36182BFB for ; Sat, 27 Oct 2018 07:32:49 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 86608C2A9 for ; Sat, 27 Oct 2018 07:32:48 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w9R7Wm8T000581 for ; Sat, 27 Oct 2018 07:32:48 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w9R7Wmf1000580 for ipfw@FreeBSD.org; Sat, 27 Oct 2018 07:32:48 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: ipfw@FreeBSD.org Subject: [Bug 213452] [patch] [ipfw] add support for ipfw ngtee/netgraph actions at layer-2 Date: Sat, 27 Oct 2018 07:32:48 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 11.0-STABLE X-Bugzilla-Keywords: patch X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: commit-hook@freebsd.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: eugen@freebsd.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Oct 2018 07:32:50 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D213452 --- Comment #3 from commit-hook@freebsd.org --- A commit references this bug: Author: eugen Date: Sat Oct 27 07:32:26 UTC 2018 New revision: 339810 URL: https://svnweb.freebsd.org/changeset/base/339810 Log: ipfw: implement ngtee/netgraph actions for layer-2 frames. Kernel part of ipfw does not support and ignores rules other than "pass", "deny" and dummynet-related for layer-2 (ethernet frames). Others are processed as "pass". Make it support ngtee/netgraph rules just like they are supported for IP packets. For example, this allows us to mirror some frames selectively to another interface for delivery to remote network analyzer over RSPAN vlan. Assuming ng_ipfw(4) netgraph node has a hook named "900" attached to "lower" hook of vlan900's ng_ether(4) node, that would be as simple as: ipfw add ngtee 900 ip from any to 8.8.8.8 layer2 out xmit igb0 PR: 213452 MFC after: 1 month Tested-by: Fyodor Ustinov Changes: head/sys/netpfil/ipfw/ip_fw_pfil.c --=20 You are receiving this mail because: You are on the CC list for the bug.=