From owner-freebsd-ipfw@freebsd.org Sun Jun 16 19:08:51 2019 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 5E66415C6BA9 for ; Sun, 16 Jun 2019 19:08:51 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from forward103j.mail.yandex.net (forward103j.mail.yandex.net [5.45.198.246]) (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 AA9F78C0B3 for ; Sun, 16 Jun 2019 19:08:49 +0000 (UTC) (envelope-from bu7cher@yandex.ru) Received: from mxback13j.mail.yandex.net (mxback13j.mail.yandex.net [IPv6:2a02:6b8:0:1619::88]) by forward103j.mail.yandex.net (Yandex) with ESMTP id 0902A6740D77; Sun, 16 Jun 2019 22:08:41 +0300 (MSK) Received: from smtp1o.mail.yandex.net (smtp1o.mail.yandex.net [2a02:6b8:0:1a2d::25]) by mxback13j.mail.yandex.net (nwsmtp/Yandex) with ESMTP id DBrEfWMZz8-8eq4a93H; Sun, 16 Jun 2019 22:08:41 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1560712121; bh=HMbBLd1AEQ6ovp8Ead+ScVWAIKqelatev1QldpPAYug=; h=In-Reply-To:From:Date:References:To:Subject:Message-ID; b=luoGUqfrOdsNbBEscFc7VXIwecMXlqb+UlBmO52t1b+CMXdMa5/ppserv1AwoSyGN vwcGi6ggD5uHISi/dWdjV1+3WpqIyx5PR5a9c3LgC8os7xvgesAqTQsa1/O11YJFtP q16Vp+a7LUabZUt+Y9KAG9YUHBVXWs8VhjrxrBLk= Received: by smtp1o.mail.yandex.net (nwsmtp/Yandex) with ESMTPSA id R415zc7h9m-8erisFC2; Sun, 16 Jun 2019 22:08:40 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) Subject: Re: ipfw: switching sets does stall the machine To: Peter , freebsd-ipfw@freebsd.org References: <20190614153302.GA4503@gate.oper.dinoex.org> <20190614172018.GJ1219@albert.catwhisker.org> <20190614201317.GA8840@gate.oper.dinoex.org> From: "Andrey V. Elsukov" Openpgp: id=E6591E1B41DA1516F0C9BC0001C5EA0410C8A17A Autocrypt: addr=bu7cher@yandex.ru; prefer-encrypt=mutual; keydata= mQENBEwBF1kBCADB9sXFhBEUy8qQ4X63Y8eBatYMHGEFWN9ypS5lI3RE6qQW2EYbxNk7qUC5 21YIIS1mMFVBEfvR7J9uc7yaYgFCEb6Sce1RSO4ULN2mRKGHP3/Sl0ijZEjWHV91hY1YTHEF ZW/0GYinDf56sYpDDehaBF5wkWIo1+QK5nmj3vl0DIDCMNd7QEiWpyLVwECgLX2eOAXByT8B bCqVhJGcG6iFP7/B9Ll6uX5gb8thM9LM+ibwErDBVDGiOgvfxqidab7fdkh893IBCXa82H9N CNwnEtcgzh+BSKK5BgvPohFMgRwjti37TSxwLu63QejRGbZWSz3OK3jMOoF63tCgn7FvABEB AAG0JUFuZHJleSBWLiBFbHN1a292IDxidTdjaGVyQHlhbmRleC5ydT6JATgEEwECACIFAkwB F1kCGwMGCwkIBwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEAHF6gQQyKF6qmYIAI6ekfm1VA4T vqankI1ISE6ku4jV7UlpIQlEbE7/8n3Zd6teJ+pGOQhN5qk8QE7utdPdbktAzi+x7LIJVzUw 4TywZLXGrkP7VKYkfg6oyCGyzITghefQeJtr2TN4hYCkzPWpylkue8MtmqfZv/6royqwTbN+ +E09FQNvTgRUYJYTeQ1qOsxNRycwvw3dr2rOfuxShbzaHBB1pBIjGrMg8fC5pd65ACH5zuFV A0CoTNGMDrEZSfBkTW604UUHFFXeCoC3dwDZRKOWJ3GmMXns65Ai5YkA63BSHEE1Qle3VBhd cG1w0CB5FBV3pB27UVnf0jEbysrDqW4qN7XMRFSWNAy5AQ0ETAEXWQEIAJ2p6l9LBoqdH/0J PEFDY2t2gTvAuzz+8zs3R03dFuHcNbOwjvWCG0aOmVpAzkRa8egn5JB4sZaFUtKPYJEQ1Iu+ LUBwgvtXf4vWpzC67zs2dDuiW4LamH5p6xkTD61aHR7mCB3bg2TUjrDWn2Jt44cvoYxj3dz4 S49U1rc9ZPgD5axCNv45j72tggWlZvpefThP7xT1OlNTUqye2gAwQravXpZkl5JG4eOqJVIU X316iE3qso0iXRUtO7OseBf0PiVmk+wCahdreHOeOxK5jMhYkPKVn7z1sZiB7W2H2TojbmcK HZC22sz7Z/H36Lhg1+/RCnGzdEcjGc8oFHXHCxUAEQEAAYkBHwQYAQIACQUCTAEXWQIbDAAK CRABxeoEEMihegkYCAC3ivGYNe2taNm/4Nx5GPdzuaAJGKWksV+w9mo7dQvU+NmI2az5w8vw 98OmX7G0OV9snxMW+6cyNqBrVFTu33VVNzz9pnqNCHxGvj5dL5ltP160JV2zw2bUwJBYsgYQ WfyJJIM7l3gv5ZS3DGqaGIm9gOK1ANxfrR5PgPzvI9VxDhlr2juEVMZYAqPLEJe+SSxbwLoz BcFCNdDAyXcaAzXsx/E02YWm1hIWNRxanAe7Vlg7OL+gvLpdtrYCMg28PNqKNyrQ87LQ49O9 50IIZDOtNFeR0FGucjcLPdS9PiEqCoH7/waJxWp6ydJ+g4OYRBYNM0EmMgy1N85JJrV1mi5i Message-ID: <083acaaf-6262-f582-11ad-71623a88786b@yandex.ru> Date: Sun, 16 Jun 2019 22:06:40 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20190614201317.GA8840@gate.oper.dinoex.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="HSv7hwntSvzXBlssvXxVb2TjLONopPRZM" X-Rspamd-Queue-Id: AA9F78C0B3 X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yandex.ru header.s=mail header.b=luoGUqfr; dmarc=pass (policy=none) header.from=yandex.ru; spf=pass (mx1.freebsd.org: domain of bu7cher@yandex.ru designates 5.45.198.246 as permitted sender) smtp.mailfrom=bu7cher@yandex.ru X-Spamd-Result: default: False [-8.94 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:5.45.192.0/19]; FREEMAIL_FROM(0.00)[yandex.ru]; HAS_ATTACHMENT(0.00)[]; RCVD_COUNT_THREE(0.00)[4]; DKIM_TRACE(0.00)[yandex.ru:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[yandex.ru,none]; MX_GOOD(-0.01)[mx.yandex.ru,mx.yandex.ru,mx.yandex.ru,mx.yandex.ru,mx.yandex.ru]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_SHORT(-0.99)[-0.994,0]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-1.74)[ipnet: 5.45.192.0/18(-4.92), asn: 13238(-3.78), country: RU(0.01)]; MIME_TRACE(0.00)[0:+,1:+,2:+]; FREEMAIL_ENVFROM(0.00)[yandex.ru]; ASN(0.00)[asn:13238, ipnet:5.45.192.0/18, country:RU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[246.198.45.5.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[yandex.ru:s=mail]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; RCVD_TLS_LAST(0.00)[]; DWL_DNSWL_LOW(-1.00)[yandex.ru.dwl.dnswl.org : 127.0.5.1]; TO_MATCH_ENVRCPT_SOME(0.00)[] 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, 16 Jun 2019 19:08:51 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --HSv7hwntSvzXBlssvXxVb2TjLONopPRZM Content-Type: multipart/mixed; boundary="Y4Pw7DtZV0Y1RDOhmXYHikMBGmYlHg1K5"; protected-headers="v1" From: "Andrey V. Elsukov" To: Peter , freebsd-ipfw@freebsd.org Message-ID: <083acaaf-6262-f582-11ad-71623a88786b@yandex.ru> Subject: Re: ipfw: switching sets does stall the machine References: <20190614153302.GA4503@gate.oper.dinoex.org> <20190614172018.GJ1219@albert.catwhisker.org> <20190614201317.GA8840@gate.oper.dinoex.org> In-Reply-To: <20190614201317.GA8840@gate.oper.dinoex.org> --Y4Pw7DtZV0Y1RDOhmXYHikMBGmYlHg1K5 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 14.06.2019 23:13, Peter wrote: > 2. There are dynamic rules involved. These do not disappear on a > "set disable". They stay and continue to function - somehow. > > 3. When a packet successfully matches a check-state, it does NOT > continue to be processed at the rule following that check-state. > Instead, it does continue to be processed at the place after > the parent keep-state rule that was originally matched! >=20 > But what if that keep-state rule is now disabled, and the new > rules do not line up in their numbering in the exact same way? > Then this packet appears at some arbitrary place in the rule > list and may go to whereever. Dynamic rules use only "action" part of parent rule, so when dynamic state is "applied" to a packet, it just executes action of parent rule without checking the set to which belongs the rule. But then, if a packet processing is continued, the next rule checked from the beginning, and thus its set is checked. > Obviousely this is not an issue if you do keep-state with simple > Allow or Deny rules - then the packets leave the system after > matching. > But such simple keep-state do not work with NAT. For NAT one needs > a more elaborate approach, like tagging and branching and > subroutine calling. > =20 > So the outcome is:=20 > =20 > When switching sets with such a configuration that introduces > branches and subroutines, the old and new rules need to precisely > line up to each other, so that the old dynamic rules (which should > be kept for the network sessions to persist) can reinsert their > matched packets at places where correct further processing happens. >=20 > Doesn't seem like an easy task... You may try 11.3-BETA where new implementation of dyn_keep_states was committed. When you set net.inet.ip.fw.dyn_keep_states=3D1, the dynamic states aren't deleted with their parents rules. They are kept until expiring or explicit deletion (with -D flag). But the next rule for states that don't stop packet processing is the last rule. This is probably will not fit your requirements. --=20 WBR, Andrey V. Elsukov --Y4Pw7DtZV0Y1RDOhmXYHikMBGmYlHg1K5-- --HSv7hwntSvzXBlssvXxVb2TjLONopPRZM 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/ iQEzBAEBCAAdFiEE5lkeG0HaFRbwybwAAcXqBBDIoXoFAl0Gk0UACgkQAcXqBBDI oXqSHQgAlAo/VOGNIFN746D/jdBgsoKPHpfvN6V4ICtXsHaqgs3StKZLAJTcWWJt VUMRpgFs5hahdnn/VzASxIWQICmJCBL7wYm7ZITb9A+c1Uj8oPbykv+CENDNbAGX +AM57VY38AEyeca7IgryCTC1+H0AuNS5b9VQ++aWuvFpAFGm5EaJfcxuCK5cx7hw 4+CXx90MhA0Lt68MIR4bRhfz2SDj7Fr9pBVxran5lVFY3OV/78wnNRdbXmqvpmb/ bJad20SN+hKAywDpGMNdUd5Ugd9XcPL++nFwhDsI654X0VLg2TYcV7qwj5GVexQN DWhcV6wiQfYDaH3FNufQcYwknig5eg== =D+Sw -----END PGP SIGNATURE----- --HSv7hwntSvzXBlssvXxVb2TjLONopPRZM--