From owner-freebsd-ipfw@freebsd.org Mon Jun 6 19:42:09 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04FEDB6DFD5 for ; Mon, 6 Jun 2016 19:42:09 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id BF80F1EB9; Mon, 6 Jun 2016 19:42:08 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.17.133] (unknown [89.113.128.32]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 8DD7024; Mon, 6 Jun 2016 22:42:05 +0300 (MSK) Reply-To: lev@FreeBSD.org To: freebsd-ipfw@freebsd.org Cc: Julian Elischer , "Alexander V. Chernikov" From: Lev Serebryakov Subject: IPFW: more "orthogonal? state operations, push into 11? Organization: FreeBSD Message-ID: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> Date: Mon, 6 Jun 2016 22:41:55 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="1MvA3V7lxPgCVfA2VpijRskUXPNKAmAt3" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 19:42:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --1MvA3V7lxPgCVfA2VpijRskUXPNKAmAt3 Content-Type: multipart/mixed; boundary="4q1Aptlrf648pN7FriSs7sL0WTxRt23tu" From: Lev Serebryakov Reply-To: lev@FreeBSD.org To: freebsd-ipfw@freebsd.org Cc: Julian Elischer , "Alexander V. Chernikov" Message-ID: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> Subject: IPFW: more "orthogonal? state operations, push into 11? --4q1Aptlrf648pN7FriSs7sL0WTxRt23tu Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I still hope to see https://reviews.freebsd.org/D1776 committed before 11-RELEASE. It seems to me, that I does everything what was requested by reviewers. Pleeeeease? --=20 // Lev Serebryakov --4q1Aptlrf648pN7FriSs7sL0WTxRt23tu-- --1MvA3V7lxPgCVfA2VpijRskUXPNKAmAt3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQJ8BAEBCgBmBQJXVdIOXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePjJkQAL1ZUofv8cSENQ0dgTRJ2Ep7 P61TyvWLbgXUlAV13puj6LwRbGV3NoroMTml7A95yH03KOkgpnYGDF3/P3ERtfzN JeIt+n9y/QHOWOsq8ZlAvyjaAQx5j4ndsD25AL4NeycUn6nSQ3iK9jTAF5CzGtZA HV7Jq+cpPCkdxX63tpAqZZMZ//ctU6aIrJtYvRF5EY7aVBaeJ2TtfWtVusQp76sd PFw5rcT857oMZzChhtiYZoc2xBxS0Vaff5UAm4myDPfMESRA1iPbWkf+af2RYOgl 8LUkePILHLdUOOwnsmBr54lDdFukYPWcTMNTLR/qnMXoUnNswsztA+3JztLph+Ne krc7zXPNxv4ZK4BEHskyJPY6H0XhiGrgz5YtBHfWoD+Zibg0GdqAK7hHGsLOGax8 KR5RIiFsejCfMAm57tkBEcAgfMaOH8pWFPv8WzRN3Acyf9/bMhB/y+eSB7i1+1If 3YGeVi1CpmYCL4o7DAMlOZvB3o+B6ZyQhs7iekcFcMDQMYVZYhAHl9eIbqxAoxuE 0ZDpRKuR8BaPdR0Z0Dm1O6UQAWve4Mn9s16L44rcgny3yJnrC2TonmkXh+bXmvSW mxXIxw5cYOIkwF0y47YFRdJn3psVetSKbDKZ3xF0qLuT7H8HBUvVLM2fyD7qDjz0 AXYspiW6lUiE6tR9mgU3 =OSME -----END PGP SIGNATURE----- --1MvA3V7lxPgCVfA2VpijRskUXPNKAmAt3-- From owner-freebsd-ipfw@freebsd.org Mon Jun 6 20:10:24 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5BFFAB6D64D for ; Mon, 6 Jun 2016 20:10:24 +0000 (UTC) (envelope-from feld@feld.me) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (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 33ACA1D57; Mon, 6 Jun 2016 20:10:24 +0000 (UTC) (envelope-from feld@feld.me) Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id EEDC220AC1; Mon, 6 Jun 2016 16:10:22 -0400 (EDT) Received: from web4 ([10.202.2.214]) by compute3.internal (MEProxy); Mon, 06 Jun 2016 16:10:23 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=feld.me; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=dEETeGSVgzth4QEp28Z+G8cUhDM=; b=F44tZL UK6J9Ua8rs6RUPx7noTn22Y/8DdUE0S5AS4L/RU25cflZJ0R+nDKYP7aRRjhOQt1 gCt4RciUsTxcTxM2qkHZQZVax7LatRRow92tIbTwQ/cGCWj0PuhFSFgkgReNIRDP WwiaPt1qaZ0Zf6ALMQ0B0SGb5/YJH8miyIAw0= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=dEETeGSVgzth4QE p28Z+G8cUhDM=; b=lfhRc4fnAy80wUyRKqMLsxS4EX55n1RUsPWntvsyO5/hsqR FDWuwQomnpNLhFZjZo19+FAI/eDE3FAkl6AvsoUSOzMqId3F78xxE6bXQqKAQLQl zL+EvB4MSRHICDmJc1Aj39ycShUaTsPkMcipToFd+9ah8AKG8mFREDq+G/Zo= Received: by mailuser.nyi.internal (Postfix, from userid 99) id BCD8ACC229; Mon, 6 Jun 2016 16:10:22 -0400 (EDT) Message-Id: <1465243822.2873034.629676161.03AA99DA@webmail.messagingengine.com> X-Sasl-Enc: 0prvq69m7IjXx+QvrnIQPJW0egGmGrnOBe3C92nhuAGW 1465243822 From: Mark Felder To: Lev Serebryakov , freebsd-ipfw@freebsd.org Cc: "Alexander V. Chernikov" , Julian Elischer MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain X-Mailer: MessagingEngine.com Webmail Interface - ajax-7f2506ab Subject: Re: IPFW: more "orthogonal? state operations, push into 11? Date: Mon, 06 Jun 2016 15:10:22 -0500 In-Reply-To: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:10:24 -0000 On Mon, Jun 6, 2016, at 14:41, Lev Serebryakov wrote: > > I still hope to see https://reviews.freebsd.org/D1776 committed before > 11-RELEASE. > > It seems to me, that I does everything what was requested by reviewers. > > Pleeeeease? > I agree, this looks very useful -- Mark Felder feld@feld.me From owner-freebsd-ipfw@freebsd.org Mon Jun 6 21:53:45 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61CEFB636BC for ; Mon, 6 Jun 2016 21:53:45 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4D5291B37; Mon, 6 Jun 2016 21:53:45 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id B44EE1A95; Mon, 6 Jun 2016 21:53:43 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: lev@FreeBSD.org, freebsd-ipfw@freebsd.org References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> Cc: "Alexander V. Chernikov" , Julian Elischer From: "Andrey V. Elsukov" Message-ID: <5755F0D3.9060909@FreeBSD.org> Date: Tue, 7 Jun 2016 00:53:23 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="4uCd7gJ6rSo13fKl1CcJaITXRpfina5JF" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 21:53:45 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --4uCd7gJ6rSo13fKl1CcJaITXRpfina5JF Content-Type: multipart/mixed; boundary="5DtqKvFN43bWq2CDFVnRFbIeOfPAaNTj0" From: "Andrey V. Elsukov" To: lev@FreeBSD.org, freebsd-ipfw@freebsd.org Cc: "Alexander V. Chernikov" , Julian Elischer Message-ID: <5755F0D3.9060909@FreeBSD.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> In-Reply-To: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> --5DtqKvFN43bWq2CDFVnRFbIeOfPAaNTj0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 06.06.16 22:41, Lev Serebryakov wrote: >=20 > I still hope to see https://reviews.freebsd.org/D1776 committed before= > 11-RELEASE. >=20 > It seems to me, that I does everything what was requested by reviewers= =2E Hi Lev, looking at provided description and examples, seems the main task you want to solve is problem with NAT. But from my point of view, you are trying to solve it in a easy way wrongly using existing methods. As you described in patch to ipfw(8) "Problem is, you need to create dynamic rule before NAT and check it after NAT actions (or vice versa) to have consistent addresses and ports." In terms of ipfw(4) a state is represented by ipfw_flow_id structure. To solve your task you just needs two states - one for not translated flow and second - for translated. Due to limits of implementation this looks impossible to solve. But proposed patch with deferred action looks too hackish to me. With the following patch you will be able create two different states, I think, and solve your task with NAT and dynamic rules: https://reviews.freebsd.org/D6674 --=20 WBR, Andrey V. Elsukov --5DtqKvFN43bWq2CDFVnRFbIeOfPAaNTj0-- --4uCd7gJ6rSo13fKl1CcJaITXRpfina5JF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXVfDYAAoJEAHF6gQQyKF6kzgH/06yoTWC0u145SmEjid96p9h j8l4M/qdvbekRVC5oHg1KjVpyCzDaZRYrvyXf5Sb3yK4EfUkbVBg33YkjlyYkY9Z o0antWtpmWOnM2+HRZt8NsVm2ofCZ+mH6paSmDWKd2+cDnBT1MSRpPTN0YYIRYhI +lDmSSESNIjdSizyYw6i5BBsjYbzeiFgfYVpoYK8UZS5NS2DnlFhdU4r2Jfmfqp1 1sTrqoW/iBt/4klSXoIaEk+LdG4KDUZ5A8kwrQpmLskfQ04e5xna+Ks+tu/NTHR5 eg8J2Lhi0pkXch7JcdVLx07Z/ei29rkCU2UgjvevQNZdzvoGKVonzy12+1fhiR0= =bO4z -----END PGP SIGNATURE----- --4uCd7gJ6rSo13fKl1CcJaITXRpfina5JF-- From owner-freebsd-ipfw@freebsd.org Tue Jun 7 06:58:52 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED5FDB6D783 for ; Tue, 7 Jun 2016 06:58:52 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from frv191.fwdcdn.com (frv191.fwdcdn.com [212.42.77.191]) (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 B2DBF1E77 for ; Tue, 7 Jun 2016 06:58:52 +0000 (UTC) (envelope-from artemrts@ukr.net) Received: from [10.10.1.23] (helo=frv199.fwdcdn.com) by frv191.fwdcdn.com with esmtp ID 1bAAYL-0007dF-Pr for freebsd-ipfw@freebsd.org; Tue, 07 Jun 2016 09:31:53 +0300 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ukr.net; s=ffe; h=Content-Transfer-Encoding:Content-Type:MIME-Version:References:In-Reply-To:Message-Id:To:Subject:From:Date; bh=1qqgl2EZ9C0xpJJpGD68OQxgJLSA8472mbdH1z4I8yo=; b=Sx61iocNkSFlw45snqEIOP5EE47nVWyqFJ+JR+7ZjLtcEL7qZPOUYJi9NG3ubTBSdN9UOFHGXjI59Rsb9sswvALk8ZneaOg/Fzd6238gJ4MrMkG2Quoa+T5sqhX7neKM11uP1zOyd1UArI8SCwIlCEiiBO2cpfkPjuhYBwRklsg=; Received: from [10.10.10.34] (helo=frv34.fwdcdn.com) by frv199.fwdcdn.com with smtp ID 1bAAYB-0007CK-1L for freebsd-ipfw@freebsd.org; Tue, 07 Jun 2016 09:31:43 +0300 Date: Tue, 07 Jun 2016 09:31:42 +0300 From: wishmaster Subject: Re[2]: IPFW: more "orthogonal? state operations, push into 11? To: freebsd-ipfw@freebsd.org X-Mailer: mail.ukr.net 5.0 Message-Id: <1465278589.404683707.3wv9pnhq@frv34.fwdcdn.com> In-Reply-To: <5755F0D3.9060909@FreeBSD.org> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> X-Reply-Action: reply Received: from artemrts@ukr.net by frv34.fwdcdn.com; Tue, 07 Jun 2016 09:31:42 +0300 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: binary Content-Disposition: inline X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 06:58:53 -0000 Hi, > With the following patch you will be able create two different states, I > think, and solve your task with NAT and dynamic rules: > https://reviews.freebsd.org/D6674 Will there be the patch in the 11-RELEASE? -- Vitaliy From owner-freebsd-ipfw@freebsd.org Tue Jun 7 08:00:38 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 873C0B6E861 for ; Tue, 7 Jun 2016 08:00:38 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 73FB7115C; Tue, 7 Jun 2016 08:00:38 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 190A365EFC; Tue, 7 Jun 2016 08:00:36 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: wishmaster , freebsd-ipfw@freebsd.org References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <1465278589.404683707.3wv9pnhq@frv34.fwdcdn.com> From: "Andrey V. Elsukov" Message-ID: <57567F14.1040201@FreeBSD.org> Date: Tue, 7 Jun 2016 11:00:20 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <1465278589.404683707.3wv9pnhq@frv34.fwdcdn.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="5fv7CGlfa21aPRaQqHqa8Lo3FrdIrB81E" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 08:00:38 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5fv7CGlfa21aPRaQqHqa8Lo3FrdIrB81E Content-Type: multipart/mixed; boundary="fdmQAksSOOnuNwp0BmP1BV5OSLuMnClnj" From: "Andrey V. Elsukov" To: wishmaster , freebsd-ipfw@freebsd.org Message-ID: <57567F14.1040201@FreeBSD.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <1465278589.404683707.3wv9pnhq@frv34.fwdcdn.com> In-Reply-To: <1465278589.404683707.3wv9pnhq@frv34.fwdcdn.com> --fdmQAksSOOnuNwp0BmP1BV5OSLuMnClnj Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07.06.16 09:31, wishmaster wrote: >> With the following patch you will be able create two different states,= I >> think, and solve your task with NAT and dynamic rules: >> https://reviews.freebsd.org/D6674 >=20 > Will there be the patch in the 11-RELEASE? Hi, there are three patches for ipfw, that I want to commit: https://reviews.freebsd.org/D6420 https://reviews.freebsd.org/D6434 https://reviews.freebsd.org/D6674 But we are in code slush and there aren't any positive review yet. So, I guess they will be committed only after 11.0 would be branched. --=20 WBR, Andrey V. Elsukov --fdmQAksSOOnuNwp0BmP1BV5OSLuMnClnj-- --5fv7CGlfa21aPRaQqHqa8Lo3FrdIrB81E Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXVn8UAAoJEAHF6gQQyKF6EfMH/imAKWpUCHzAMrpHnwQsVaJO hiRogKZv4fT4Qtr4RWkqMoOPFIB5Gc6Gk6jNz/DTjU7UOfpbemswJ8CmfnXSRDeT yEqBbOAMsZjSlb6oiLvNlUp2p332whVWKADe59qGGxv8u1cEb1oQYKjmOV2zacAJ Kv6gcPrtCw3pVqZ3ZUiNSUJu67EAhef0GwNQUwwjkh15IWUwaKOep9LwAmRlvXnI jMb/M8qjSy11YBgnHcdy/ge4USsqOMzudsLjLaPNhcyhtAfZoLczTCbwYuBRfgpl ihw8g4EnN0O/Ar/39iO4HoW5ShKtFiYXYRrAqRyi2SvsQxsDABq2PVp9+uKdquQ= =/o5S -----END PGP SIGNATURE----- --5fv7CGlfa21aPRaQqHqa8Lo3FrdIrB81E-- From owner-freebsd-ipfw@freebsd.org Tue Jun 7 14:31:15 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA406B6D72F for ; Tue, 7 Jun 2016 14:31:15 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) 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 1B8D1115B; Tue, 7 Jun 2016 14:31:14 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u57EV3A7007481; Wed, 8 Jun 2016 00:31:04 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 8 Jun 2016 00:31:03 +1000 (EST) From: Ian Smith To: "Andrey V. Elsukov" cc: lev@freebsd.org, freebsd-ipfw@freebsd.org, Julian Elischer , "Alexander V. Chernikov" Subject: Re: IPFW: more "orthogonal? state operations, push into 11? In-Reply-To: <5755F0D3.9060909@FreeBSD.org> Message-ID: <20160607220136.R15883@sola.nimnet.asn.au> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20160607220136.B15883@sola.nimnet.asn.au> X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 14:31:15 -0000 On Tue, 7 Jun 2016 00:53:23 +0300, Andrey V. Elsukov wrote: > On 06.06.16 22:41, Lev Serebryakov wrote: > > > > I still hope to see https://reviews.freebsd.org/D1776 committed before > > 11-RELEASE. > > > > It seems to me, that I does everything what was requested by reviewers. > > Hi Lev, > > looking at provided description and examples, seems the main task you > want to solve is problem with NAT. But from my point of view, you are > trying to solve it in a easy way wrongly using existing methods. > > As you described in patch to ipfw(8) "Problem is, you need to create > dynamic rule before NAT and check it after NAT actions (or vice versa) > to have consistent addresses and ports." > > In terms of ipfw(4) a state is represented by ipfw_flow_id structure. > To solve your task you just needs two states - one for not translated > flow and second - for translated. Due to limits of implementation this > looks impossible to solve. But proposed patch with deferred action looks > too hackish to me. > > With the following patch you will be able create two different states, I > think, and solve your task with NAT and dynamic rules: > https://reviews.freebsd.org/D6674 If your patch does what Lev wanted to achieve with (I thought too many) new dynamic rule actions, then I think your simpler solution is better, not least because it's far easier to understand for non-Julians :) Looking from a useability and documentation perspective only - I won't even be looking at this code - I have a few thoughts: Thus far, keep-state and limit seem to be interchangeable options; limit rules will need to work the same with respect to named dynamic flows; do I assume that you've just started with only keep-state for testing? I think flow names should be specified as an _optional_ parameter, thus: check-state [name] keep-state [name] limit {src-addr | src-port | dst-addr | dst-port} N [name] where name (maybe flowname, for easier comprehension by man readers?) is optional, assigned as 'default' whenever omitted - as well as being for backwards ruleset compatibility, which then only needs mentioning once, and maybe also put another way in the STATEFUL FIREWALL section. So a few of the existing example rules with no name could stand, while others (see below) append names of OUTBOUND and INBOUND or whatever. As is, you have 740 .It Cm check-state Op Ar name | Cm any | Cm default which in other contexts would mean you have to supply one of 'name' or 'any' or 'default' when you don't have to provide one, 'default' being assigned otherwise. Otherwise I think this is fairly well described. Will 'ipfw -[e]d list|show' show the flow names? or the indices? As I pestered Lev about last year, we still need a small example ruleset section that actually deals with potentially problematic stateful issues with NAT - which I still don't fully understand - beyond descriptions in the abstract case; ie an actual working dual- or multi-flow example. I know these are "just doc" issues of little importance while testing working code, and I haven't supplied any patches, so are just FWIW .. cheers, Ian From owner-freebsd-ipfw@freebsd.org Wed Jun 8 00:12:39 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 33653B6EBFB for ; Wed, 8 Jun 2016 00:12:39 +0000 (UTC) (envelope-from donileo@gmail.com) Received: from mail-qg0-x22e.google.com (mail-qg0-x22e.google.com [IPv6:2607:f8b0:400d:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D28AD1116; Wed, 8 Jun 2016 00:12:38 +0000 (UTC) (envelope-from donileo@gmail.com) Received: by mail-qg0-x22e.google.com with SMTP id p34so67011313qgp.1; Tue, 07 Jun 2016 17:12:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=3x7hzxhDej2POBd2PpbnSNUif5mpbwJ4ufRwv/sYD7Y=; b=NiUvyIIrIVg5ZK23OQb8rgrtRyEFivfTASfEx7K4gL0CGON008zz7GM0OQXhidVlBH H7P2BYWwOBw5I9PsSPdesaEDqre9I+N3+m3pf3vAf7EXdsvUWng2eSnzOh4aBRqmpD2a oLnqfqDwGuFyOgnG2MIwlYk69liHV9B5pwdebx4UmAFtLQEdaFqAZA4ohymu03o6OZMk 7JTRYo7+lr+eF+fScDoqmqp7G5jcoz2JLPMkXW//y34OOTLJ+0lbIKyPSLHgiTzVoae5 Xo0R0kNdbZPlkuO8k9jI9K5ga30Pfa8Ectqp37sHPpVPTAcZd7KULb+Pm3HAT0H1g29G EcvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=3x7hzxhDej2POBd2PpbnSNUif5mpbwJ4ufRwv/sYD7Y=; b=PUzRab0Ngs5M6PZTbFXngoL0ktSV/upyQJzHUq67CyPUFRvcYTwQfhwXoPGEzy7QQF bJ7wrEVaxhCembtEdyQCO+pOmVhcxmhJyJcWGqlvmwZGmvhoPhkDIZ6aDari5u2jj0Kr /pDSpE7rVhaxBJlMDEx3063k+3Ann6axJ8gsNxca9e7oKqfTel6SYhICY/2dzn0UwKh2 PXbgr9DyDtntWRB5Blm3baAi+NoyxJDYEQF1UxW8bHPEpZCzHyiKIBtLxApRQBwmponZ Aj4aNZjLZHxUymG4W433MibSRfvFi7wt0LaZQQdpX7tmkhHK+sR5Ajfn0QAiPsTEOCW/ Sk2w== X-Gm-Message-State: ALyK8tJWN1ArS6NsoM/WmKvaOs8r3V4edx1skSGjtR2YwkoJQ6tm8Kd/NCPCIpWFbcXQgQ== X-Received: by 10.140.29.9 with SMTP id a9mr2074778qga.37.1465344757641; Tue, 07 Jun 2016 17:12:37 -0700 (PDT) Received: from [192.168.1.5] (c-24-0-16-19.hsd1.nj.comcast.net. [24.0.16.19]) by smtp.gmail.com with ESMTPSA id f12sm2515945qta.9.2016.06.07.17.12.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 07 Jun 2016 17:12:36 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Subject: Re: ipfw fwd sends to port but also through gateway From: Adonis Peralta In-Reply-To: <541DA7C0-DE8D-4F83-B5A1-8BDB6E8320AE@gmail.com> Date: Tue, 7 Jun 2016 20:12:34 -0400 Cc: freebsd-ipfw@freebsd.org Message-Id: <0110442D-1555-440D-8675-E7814E17A80F@gmail.com> References: <9227BA17-B289-494D-8A82-603DB1B35457@gmail.com> <98c5b4fe-151f-1be1-7d29-89a89c5616ec@freebsd.org> <4270A86E-2451-4EE1-8B90-99B1331EEDFD@gmail.com> <87df5467-9918-fbe4-83ee-dee4c38b73f8@freebsd.org> <541DA7C0-DE8D-4F83-B5A1-8BDB6E8320AE@gmail.com> To: Julian Elischer X-Mailer: Apple Mail (2.3124) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 00:12:39 -0000 For Test #1 you are correct that to solely test if the fwd was = terminating the search the rule should have been add 13 deny log logamount 5 tcp from 192.168.1.0/24{1-5,7-254} to any = dst-port 80 in via igb0 I went ahead and tested that and YES the search does properly terminate.=20= The rule that I had added "00013 deny log logamount 5 tcp from any 80 to = any via igb0=E2=80=9D however was meant to show the weird behavior that = I was seeing. As I had mentioned before, nothing was running on 8080, 80, 8083 for = these tests. I purposely stopped squid, nginx, and anything but the base = system utilities. I definitely get that its super weird to see my = freebsd box responding back to the client by spoofing the ip address on = its own, but thats what happening for me. I think somehow what is = happening is that since the packet comes in to the freebsd box even = though the dst address of the packet is not the same as the system, the = system simply responds back as if the packet was intended for it.. Is = there any sysctl variable or anything that would cause my box to respond = back as a proxy on its own? I don=E2=80=99t believe the behavior I'm = stating here should be happening. It doesn't happen without the fwd rule = and as soon as I put the fwd rule the bad behavior happens. Like I = previously stated in my last email, even If I completely block internet = (outside) access to my freebsd box to make sure none of the packets make = it to the actual website and therefore prevent any site from responding = back via my freebsd machine, the behavior above still happens. Here is the result of the sockstat command to show what listening ports = are currently running. $ sockstat -46 -l unbound unbound 5461 3 udp6 ::1:53 *:* unbound unbound 5461 4 tcp6 ::1:53 *:* unbound unbound 5461 5 udp4 127.0.0.1:53 *:* unbound unbound 5461 6 tcp4 127.0.0.1:53 *:* root sshd 922 3 tcp6 *:22 *:* root sshd 922 4 tcp4 *:22 *:* root smbd 865 27 tcp6 *:445 *:* root smbd 865 28 tcp6 *:139 *:* root smbd 865 29 tcp4 *:445 *:* root smbd 865 30 tcp4 *:139 *:* root nmbd 862 9 udp4 *:137 *:* root nmbd 862 10 udp4 *:138 *:* root nmbd 862 11 udp4 192.168.1.6:137 *:* root nmbd 862 12 udp4 192.168.1.255:137 *:* root nmbd 862 13 udp4 192.168.1.6:138 *:* root nmbd 862 14 udp4 192.168.1.255:138 *:* root ntpd 830 20 udp6 *:123 *:* root ntpd 830 21 udp4 *:123 *:* root ntpd 830 22 udp4 192.168.1.6:123 *:* root ntpd 830 23 udp6 ::1:123 *:* root ntpd 830 24 udp6 fe80::1%lo0:123 *:* root ntpd 830 25 udp4 127.0.0.1:123 *:* root syslogd 742 6 udp6 *:514 *:* root syslogd 742 7 udp4 *:514 *:* Here is my sysctl.conf net.inet.ip.fw.one_pass=3D0 net.inet.ip.forwarding=3D1 net.inet.ip.fastforwarding=3D1 = =20 net.inet.tcp.tso=3D0 = =20 net.inet.tcp.msl=3D7500 net.inet.tcp.delayed_ack=3D0 net.inet.ip.fw.verbose_limit=3D5 In my rc.conf gateway_enable =3D =E2=80=9CYES=E2=80=9D is set. Thanks, Adonis >=20 >=20 >> On May 30, 2016, at 2:13 AM, Julian Elischer > wrote: >>=20 >> On 28/05/2016 1:39 PM, Adonis Peralta wrote: >>> Ok so some more information on what I am seeing, Now even a little = more weird. My system is a relative stock FreeBSD 10.3 Release with = latest patches installed. Pretty much stock with very little amount of = third party libraries running. >>>=20 >>> Test #1 =E2=80=94 Lets add an additional rule after the fwd to see = if the fwd is not terminating the search. Also, for this test I stopped = Squid completely as a service and verified its not running. Nothing on = port 80 is running either. >>> Make a request to cnn.com via client. >>>=20 >>> 00010 allow ip from any to any via lo0 >>>=20 >>> 00012 fwd 127.0.0.1,8083 tcp from 192.168.1.0/24{1-5,7-254} to any = dst-port 80 in via igb0 #original fwd rule >>>=20 >>> 00013 deny log logamount 5 tcp from any 80 to any via igb0 #new = additional rule to test if fwd is terminating search >> don't you mean=20 >> add 13 deny log logamount 5 tcp from 192.168.1.0/24{1-5,7-254} to any = dst-port 80 in via igb0 >> to see if the original packet gets pas the fwd? >>>=20 >>> 00015 allow ip from 192.168.1.0/24 to any in via igb0 >>> 00016 deny ip from any to any not antispoof in >>> 00030 check-state >>> 00040 allow tcp from any to any out via igb0 setup keep-state >>> 00041 allow ip from any to any out via igb0 keep-state >>> 00050 deny ip from 192.168.0.0/16 to any in via igb0 >>> 00051 deny ip from 172.16.0.0/12 to any in via igb0 >>> 00052 deny ip from 10.0.0.0/8 to any in via igb0 >>> 00053 deny ip from 127.0.0.0/8 to any in via igb0 >>> 00054 deny ip from 0.0.0.0/8 to any in via igb0 >>> 00055 deny ip from 169.254.0.0/16 to any in via igb0 >>> 00056 deny ip from 192.0.2.0/24 to any in via igb0 >>> 00057 deny ip from 204.152.64.0/23 to any in via igb0 >>> 00058 deny ip from 224.0.0.0/3 to any in via igb0 >>> 00070 deny tcp from any to any dst-port 113 in via igb0 >>> 00080 deny tcp from any to any dst-port 137 in via igb0 >>> 00081 deny tcp from any to any dst-port 138 in via igb0 >>> 00082 deny tcp from any to any dst-port 139 in via igb0 >>> 00083 deny tcp from any to any dst-port 81 in via igb0 >>> 00100 deny log logamount 5 tcp from any to any established in via = igb0 >>> 00499 deny log logamount 5 ip from any to any >>> 00500 allow ip from any to any >>> 00599 deny log logamount 5 ip from any to any >>> 65535 deny ip from any to any >>>=20 >>> When I add rule 00013 to ipfw and restart it.. I get something very = very interesting in the logs: >>>=20 >>> May 28 00:51:29 bruce kernel: ipfw: 13 Deny TCP 157.166.226.26:80 = 192.168.1.3:62805 out via igb0 #####157.166.226.26 port 80 is the dns = -resolved address of a website I made a request to via my client. But = this is going OUT through my local lan link=E2=80=A6 What??? >> this is normal. >> the fwd rule activaed IP spoofing on the proxy.. the proxy is = responding to the original client as if it were the original = destination. >> of course if hte proxy is not running hten something else must hav ea = socket open in listen mode. >>=20 >>> May 28 00:51:29 bruce kernel: ipfw: 13 Deny TCP 157.166.226.25:80 = 192.168.1.3:62806 out via igb0 >>> May 28 00:51:30 bruce kernel: ipfw: 13 Deny TCP 157.166.226.26:80 = 192.168.1.3:62805 out via igb0 >>> May 28 00:51:30 bruce kernel: ipfw: 13 Deny TCP 157.166.226.25:80 = 192.168.1.3:62806 out via igb0 >>> May 28 00:51:31 bruce kernel: ipfw: 13 Deny TCP 157.166.226.26:80 = 192.168.1.3:62805 out via igb0 >>> May 28 00:51:31 bruce kernel: ipfw: limit 5 reached on entry 13 >>>=20 >>> As you can see above somehow someway my FreeBSD machine (bruce) is = sending back responses back to the client by by using the requested = website ip as its own ip now. That is super weird. The ip of my freebsd = machine is 192.168.1.6 not what you see above.=20 >>=20 >>> I don=E2=80=99t believe any service is responsible for the above as = (squid is not running, neither is any program binded to 8080 or 80) but = yet somehow my bsd machine is for some it reason attempting to respond = on its own back to the client using the destination ip address the = client made a request to as its SRC address now. >>>=20 >> Something must have a socket 8083 open that is responding. >> unless the bug is that it is not being selective, and the 8083 is = getting lost, and ANY socket that is listening is getting the packet. >>=20 >>=20 >>> Now as crazy as that sounds, I went ahead and tried to take a look = more closely at my tcpdump to see what I can find there. Here is some = relevant data: >>>=20 >>> 192.168.1.3.62805 > 157.166.226.26.http: Flags [S], cksum 0x7776 = (correct), seq 31167568, win 65535, options [mss 1460,nop,wscale = 5,nop,nop,TS val 321249059 ecr 0,sackOK,eol], length 0 >>>=20 >>> 00:51:29.741052 IP (tos 0x0, ttl 63, id 34976, offset 0, flags [DF], = proto TCP (6), length 64) >>> 192.168.1.3.62806 > 157.166.226.25.http: Flags [S], cksum 0x2a5b = (correct), seq 1085448749, win 65535, options [mss 1460,nop,wscale = 5,nop,nop,TS val 321249162 ecr 0,sackOK,eol], length 0 >>>=20 >>> Ok=E2=80=A6 Not much to see there because the 00013 is rule is = actually blocking the outbound traffic.. Lets take away the 00013 rule = and see what tcpdump gives us: >>>=20 >> no your rule is blocking the return packets from the proxy to the = client I think >>=20 >>> 01:08:23.047688 IP (tos 0x0, ttl 63, id 40357, offset 0, flags [DF], = proto TCP (6), length 64) >>> 192.168.1.3.62857 > 157.166.226.25.http: Flags [S], cksum 0xe105 = (correct), seq 691019997, win 65535, options [mss 1460,nop,wscale = 5,nop,nop,TS val 321765751 ecr 0,sackOK,eol], length 0 >>>=20 >>> 01:08:23.047739 IP (tos 0x0, ttl 63, id 14370, offset 0, flags [DF], = proto TCP (6), length 40) >>> 157.166.226.25.http > 192.168.1.3.62857: Flags [R.], cksum 0x4186 = (incorrect -> 0x2e7d), seq 0, ack 691019998, win 0, length 0 >>>=20 >>> 01:08:23.211028 IP (tos 0x0, ttl 63, id 61609, offset 0, flags [DF], = proto TCP (6), length 64) >>> 192.168.1.3.62858 > 157.166.226.26.http: Flags [S], cksum 0xda95 = (correct), seq 2457714015, win 65535, options [mss 1460,nop,wscale = 5,nop,nop,TS val 321765909 ecr 0,sackOK,eol], length 0 >>>=20 >>> 01:08:23.211081 IP (tos 0x0, ttl 63, id 14383, offset 0, flags [DF], = proto TCP (6), length 40) >>> 157.166.226.26.http > 192.168.1.3.62858: Flags [R.], cksum 0x4187 = (incorrect -> 0x28ab), seq 0, ack 2457714016, win 0, length 0 >>>=20 >>> Ok so pay attention to the response times.. 01:08:23.047688 a = request comes from the client.. and at 01:08:23.047739 a response goes = back to the client??? Really? A network request to a website took less = than .000051 seconds to go across and come back?? No way.. This response = is for sure coming back from my machine.=20 >> yes it is.. that is what local fwd does. it's for transparent proxy. = it wouldn't be transparent otherwise. >>=20 >>>=20 >>> Considering how weird this is (Never seen this before) I went ahead = and then essentially killed the internet connection on my FreeBSD = machine (basically I blocked all requests at the router level to outside = the local lan) and again made a request to cnn.com . = What did I find? The same results as above.. My bsd machine attempts to = sends replies back using the requested DST IP as the SRC address. = TcpDump confirms the same. This definitely tells me that the above = packets are sent by my BSD machine as theres no way any remote machine = outside my local lan got any requests to even respond... >>>=20 >>> So fine..lets continue testing further.. Lets remove the fwd rule = 00012 and see what we get.. >>>=20 >>> Test #2 - Remove the fwd rule =E2=80=94 No squid or service running = on port 8080 or 80. Restore the internet connection on the BSD machine. >>> Make a request to cnn.com via client. >>>=20 >>> Our pertinent ipfw rules become: >>>=20 >>> 00010 allow ip from any to any via lo0 >>>=20 >>> 00013 deny log logamount 5 tcp from any 80 to any via igb0 #This = Rule stays fwd rule gets removed >>>=20 >>> 00015 allow ip from 192.168.1.0/24 to any in via igb0 >>> 00016 deny ip from any to any not antispoof in >>> 00030 check-state >>> 00040 allow tcp from any to any out via igb0 setup keep-state >>> 00041 allow ip from any to any out via igb0 keep-state >>> 00050 deny ip from 192.168.0.0/16 to any in via igb0 >>> 00051 deny ip from 172.16.0.0/12 to any in via igb0 >>> 00052 deny ip from 10.0.0.0/8 to any in via igb0 >>> 00053 deny ip from 127.0.0.0/8 to any in via igb0 >>> 00054 deny ip from 0.0.0.0/8 to any in via igb0 >>> 00055 deny ip from 169.254.0.0/16 to any in via igb0 >>> 00056 deny ip from 192.0.2.0/24 to any in via igb0 >>> 00057 deny ip from 204.152.64.0/23 to any in via igb0 >>> 00058 deny ip from 224.0.0.0/3 to any in via igb0 >>> 00070 deny tcp from any to any dst-port 113 in via igb0 >>> 00080 deny tcp from any to any dst-port 137 in via igb0 >>> 00081 deny tcp from any to any dst-port 138 in via igb0 >>> 00082 deny tcp from any to any dst-port 139 in via igb0 >>> 00083 deny tcp from any to any dst-port 81 in via igb0 >>> 00100 deny log logamount 5 tcp from any to any established in via = igb0 >>> 00499 deny log logamount 5 ip from any to any >>> 00500 allow ip from any to any >>> 00599 deny log logamount 5 ip from any to any >>> 65535 deny ip from any to any >>>=20 >>> What are our results? Rule 00013 doesn=E2=80=99t get matched as in = Test #1 and we see no logs pertaining 13 Deny TCP as in Test#1. But what = does tcpdump give us? >>>=20 >>> 01:19:25.047593 IP (tos 0x0, ttl 63, id 27280, offset 0, flags [DF], = proto TCP (6), length 64) >>> 192.168.1.3.62898 > 157.166.226.26.http: Flags [S], cksum 0xc08f = (correct), seq 3330522041, win 65535, options [mss 1460,nop,wscale = 5,nop,nop,TS val 322152845 ecr 0,sackOK,eol], length 0 >>>=20 >>> 01:19:25.047612 IP (tos 0x0, ttl 62, id 27280, offset 0, flags [DF], = proto TCP (6), length 64) >>> 192.168.1.3.62898 > 157.166.226.26.http: Flags [S], cksum 0xc08f = (correct), seq 3330522041, win 65535, options [mss 1460,nop,wscale = 5,nop,nop,TS val 322152845 ecr 0,sackOK,eol], length 0 >>>=20 >>> 01:19:25.047731 IP (tos 0x0, ttl 61, id 27280, offset 0, flags [DF], = proto TCP (6), length 64) >>> 192.168.1.3.62898 > 157.166.226.26.http: Flags [S], cksum 0xc08f = (correct), seq 3330522041, win 65535, options [mss 1460,nop,wscale = 5,nop,nop,TS val 322152845 ecr 0,sackOK,eol], length 0 >>>=20 >>> 01:19:25.047739 IP (tos 0x0, ttl 60, id 27280, offset 0, flags [DF], = proto TCP (6), length 64) >>> 192.168.1.3.62898 > 157.166.226.26.http: Flags [S], cksum 0xc08f = (correct), seq 3330522041, win 65535, options [mss 1460,nop,wscale = 5,nop,nop,TS val 322152845 ecr 0,sackOK,eol], length 0 >>>=20 >>> 01:19:25.047853 IP (tos 0x0, ttl 59, id 27280, offset 0, flags [DF], = proto TCP (6), length 64) >>> 192.168.1.3.62898 > 157.166.226.26.http: Flags [S], cksum 0xc08f = (correct), seq 3330522041, win 65535, options [mss 1460,nop,wscale = 5,nop,nop,TS val 322152845 ecr 0,sackOK,eol], length 0 >>>=20 >>>=20 >>> So ok, the traffic now goes back to normal. This definitely tells us = that whatever this weird behavior I am seeing seems to be tied to the = fwd rule. It also tells us that this is not related to squid as for both = tests squid was not running as was no service on port 8080 or 80. >>>=20 >>>=20 >>> As far as Squid, whenever Squid is running what will happen is that = I get the same traffic as in Test #1 but now squid picks up some of = those packets as requests to itself and will masquerade and send = requests down by using the server ip (as SRC) and it does respond back = to the client correctly. However because of the additional traffic in = Test #1 (what bsd sends back from 157.166.226.26) that shouldn=E2=80=99t = be there the TCP flow between the client and squid gets messed up to the = point of many TCP retransmissions and overall a sluggish or very very = bad connection squid via my client. >>>=20 >>> Hope this info helps and let me know if you any more details from my = test. >>>=20 >>> Thanks, >>> Adonis >>>=20 >>>> On May 26, 2016, at 10:28 AM, Julian Elischer > wrote: >>>>=20 >>>> On 26/05/2016 2:03 AM, Adonis Peralta wrote: >>>>> Hi all, >>>>>=20 >>>>> I am noticing something weird in regards to ipfw forwarding when I = am attempting to set up squid web proxying. >>>>>=20 >>>>> Here is the info: >>>>>=20 >>>>> ipfw rule: ipfw -q add fwd 127.0.0.1,8080 tcp from = 192.168.1.0/24{1-5,7-254} to any dst-port 80 in via igb0 //I exclude the = servers ip 192.168.1.6 here to prevent a loop >>>>> Squid Proxy: running on localhost (127.0.0.1) port 8080. >>>>> Freebsd box ip: 192.168.1.6 >>>>> Router box: 192.168.1.1 >>>>>=20 >>>>> Essentially when any ip (not my freebsd ip) makes a request to = port 80 my router will route that ip using policy based routing to my = freebsd box. Then the ipfw fwd rule above sends that traffic over to my = squid proxy port. This is working fine and the fwd rule above does = definitely match. >>>>> However the issue Im seeing is that ipfw fwd not only sends the = packet out to the squid proxy but ALSO sends it out to the original = destination causing all sorts of issues for my client because it messes = up the tcp flow/handshaking. >>>>>=20 >>>>> To be more clear what I see is when client 192.168.1.3 makes a = request on port 80=E2=80=A6 my freebsd box receives it.. then forwards = it to squid but also sends it out to the original destination so for = every packet coming to port 80 i see two going out.. >>>>>=20 >>>>> To debug this problem a bit further I stopped squid, and setup "nc = -l 8080" to catch incoming requests via the fwd. >>>>>=20 >>>>> Doing a tcpdump I see: >>>>>=20 >>>>> 192.168.1.3.57653 > s3-us-west-1.amazonaws.com.http: Flags [S], = cksum 0x9385 (correct), seq 1939422713, win 65535, options [mss = 1460,nop,wscale 5,nop,nop,TS val 1149232947 ecr 0,sackOK,eol], length 0 >>>>> 13:14:16.209753 IP (tos 0x0, ttl 64, id 10951, offset 0, flags = [DF], proto TCP (6), length 60) >>>>> s3-us-west-1.amazonaws.com.http > 192.168.1.3.57653: Flags = [S.], cksum 0xe4da (incorrect -> 0x8343), seq 3934654233, ack = 1939422714, win 65535, options [mss 1460,nop,wscale 6,sackOK,TS val = 1794161828 ecr 1149232947], length 0 >>>>>=20 >>>>> Netcat catches the HTTP Get request (i can see it in netcats = console).. but the above tcpdump definitely tells me that the request = was also sent to to aws itself this is implied by the fact that aws = responded back to original ip (192.168.1.3). >>>>>=20 >>>>> When I have squid running I see the same thing in the above = tcpdump but also communication between my freebsd box ip 192.168.1.6 and = the requested http site. >>>>>=20 >>>>> Why is this happening? Is this a bug? >>>> definitely sounds like a bug.. The fwd rule is supposed to = terminate the search.. Can you confirm that a matching rule following = the fwd does not see the packet continuing on? I used it for many years = and it acted as expected. >>>> Is there any rule you can add that catches the outgoing extra = packet and blocks it (as a work-around) >>>> what does squid's outgoing packet look like? is it masquerading the = client or is it using its own address? >>>>=20 >>>>=20 >>>>>=20 >>>>> -Adonis >>>>> _______________________________________________ >>>>> freebsd-ipfw@freebsd.org mailing = list >>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw = >>>>> To unsubscribe, send any mail to " = freebsd-ipfw-unsubscribe@free= bsd.org " >>>=20 >>=20 >>=20 >=20 From owner-freebsd-ipfw@freebsd.org Wed Jun 8 09:28:13 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7355CB6F31B for ; Wed, 8 Jun 2016 09:28:13 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (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 3F5EF1655 for ; Wed, 8 Jun 2016 09:28:13 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from vader9.bultmann.eu (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id D115F1E03 for ; Wed, 8 Jun 2016 11:28:10 +0200 (CEST) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: freebsd-ipfw@freebsd.org References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <1465278589.404683707.3wv9pnhq@frv34.fwdcdn.com> <57567F14.1040201@FreeBSD.org> From: Jan Bramkamp Message-ID: Date: Wed, 8 Jun 2016 11:28:09 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <57567F14.1040201@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 09:28:13 -0000 On 07/06/16 10:00, Andrey V. Elsukov wrote: > On 07.06.16 09:31, wishmaster wrote: >>> With the following patch you will be able create two different states, I >>> think, and solve your task with NAT and dynamic rules: >>> https://reviews.freebsd.org/D6674 >> >> Will there be the patch in the 11-RELEASE? > > Hi, > > there are three patches for ipfw, that I want to commit: > https://reviews.freebsd.org/D6420 > https://reviews.freebsd.org/D6434 > https://reviews.freebsd.org/D6674 > > But we are in code slush and there aren't any positive review yet. So, I > guess they will be committed only after 11.0 would be branched. To bad. Those all look very useful and and together would enable me to use my FreeBSD jail hosts for all packet filtering instead of running the traffic through a OpenBSD bhyve guest on each jail host. From owner-freebsd-ipfw@freebsd.org Wed Jun 8 10:09:06 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F2343B6F337 for ; Wed, 8 Jun 2016 10:09:06 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: from mail-vk0-x235.google.com (mail-vk0-x235.google.com [IPv6:2607:f8b0:400c:c05::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ABA4D1766 for ; Wed, 8 Jun 2016 10:09:06 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: by mail-vk0-x235.google.com with SMTP id g67so4249906vkb.3 for ; Wed, 08 Jun 2016 03:09:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to; bh=elMaDjeXcfuXNto35UAvSp0vLA2Smt3kK2QvO6KIqOU=; b=HsD+XWXDgSfnIvvNbqbN3a5CNPDMx0TRk8IgrgCT/dd71sJrXXcfrcLfaC8aNASA9W Ay9HCr1ZLOKF4hlDqO8kzjw3W34nUb+20EEVO5KxWUqnkJDQr46lVKAqp5Q4hNHTs0or CNofzZIxP8FHSdbFFFYV4A5ZFlKhqaD/zLznW5rXANOeNehTh23NxAbRQ7LL/tXg6gD0 rRfU7GhUTdELHF/pv3+c0BN05lIldztVLI9x6gYCJt2byJuo4gzpmUKtr4PH//KSC4EO pKiGvUTB6M+917WorZjuVNtMNWQI0tSW71KI/iUMBOJgbjfX8IvP8TN4y6MdvdT+A4Eh //5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to; bh=elMaDjeXcfuXNto35UAvSp0vLA2Smt3kK2QvO6KIqOU=; b=MWz/Ksw4f7pKEGjOwQJissmGiqFz2LGFfw+2mLIeDLrKuIeeMJFwr3BedMueR5ZWTo XiHz1nh20XoC+kUsxvco9lrZHVr9tB2SIZPkmCREg9wdHvPuwVLrhnEKjWxB/DEJoXpt mJ8u8TYXOhOFafTrSUiNf4J0igRG6a4xd4p0Fvlwo4VbdSKUTf6SEAwLFIFA/xptl/1G 315xKtjhkqpbArlalsjM0K8dEbqEhzt4k+p6GKSnYXpPkChSTxe2ksLLOKriUZTv7LE2 W5HxrZ9Vn5LE1HfLLBMiRUGB4wuhlb4jEU3ukDYf3NHRxWPja4n2OxJtUpiWUvRcZok7 074A== X-Gm-Message-State: ALyK8tJjRCSJBOCyGJzCG+xTblsMkEj+nlE0Ame35sdZRsJslxy4UMBK9hEh436wAKVYig6+JEAZkSglPpaCZA== X-Received: by 10.31.167.84 with SMTP id q81mr1915477vke.51.1465380545786; Wed, 08 Jun 2016 03:09:05 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.37.69 with HTTP; Wed, 8 Jun 2016 03:09:05 -0700 (PDT) Reply-To: bycn82@dragonflybsd.org In-Reply-To: References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <1465278589.404683707.3wv9pnhq@frv34.fwdcdn.com> <57567F14.1040201@FreeBSD.org> From: Bill Yuan Date: Wed, 8 Jun 2016 18:09:05 +0800 Message-ID: Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: freebsd-ipfw Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 10:09:07 -0000 It is more and more complex here! On 8 June 2016 at 17:28, Jan Bramkamp wrote: > On 07/06/16 10:00, Andrey V. Elsukov wrote: > >> On 07.06.16 09:31, wishmaster wrote: >> >>> With the following patch you will be able create two different states, I >>>> think, and solve your task with NAT and dynamic rules: >>>> https://reviews.freebsd.org/D6674 >>>> >>> >>> Will there be the patch in the 11-RELEASE? >>> >> >> Hi, >> >> there are three patches for ipfw, that I want to commit: >> https://reviews.freebsd.org/D6420 >> https://reviews.freebsd.org/D6434 >> https://reviews.freebsd.org/D6674 >> >> But we are in code slush and there aren't any positive review yet. So, I >> guess they will be committed only after 11.0 would be branched. >> > > To bad. Those all look very useful and and together would enable me to use > my FreeBSD jail hosts for all packet filtering instead of running the > traffic through a OpenBSD bhyve guest on each jail host. > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@freebsd.org Wed Jun 8 10:37:00 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CD8D2B6F903 for ; Wed, 8 Jun 2016 10:37:00 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A7D241518; Wed, 8 Jun 2016 10:37:00 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id 672B566D67; Wed, 8 Jun 2016 10:36:58 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: Ian Smith References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <20160607220136.R15883@sola.nimnet.asn.au> Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" , lev@freebsd.org, Julian Elischer From: "Andrey V. Elsukov" Message-ID: <5757F533.8070907@FreeBSD.org> Date: Wed, 8 Jun 2016 13:36:35 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <20160607220136.R15883@sola.nimnet.asn.au> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="xOITXn1oB5rwCOQoPtVqiPBUeh7J4aVPt" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 10:37:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --xOITXn1oB5rwCOQoPtVqiPBUeh7J4aVPt Content-Type: multipart/mixed; boundary="gTPAdF5CHc0LSPHQSOWlax3wDqkGDV1vX" From: "Andrey V. Elsukov" To: Ian Smith Cc: freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" , lev@freebsd.org, Julian Elischer Message-ID: <5757F533.8070907@FreeBSD.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <20160607220136.R15883@sola.nimnet.asn.au> In-Reply-To: <20160607220136.R15883@sola.nimnet.asn.au> --gTPAdF5CHc0LSPHQSOWlax3wDqkGDV1vX Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 07.06.16 17:31, Ian Smith wrote: > If your patch does what Lev wanted to achieve with (I thought too many)= =20 > new dynamic rule actions, then I think your simpler solution is better,= =20 > not least because it's far easier to understand for non-Julians :) >=20 > Looking from a useability and documentation perspective only - I won't = > even be looking at this code - I have a few thoughts: >=20 > Thus far, keep-state and limit seem to be interchangeable options; limi= t=20 > rules will need to work the same with respect to named dynamic flows; d= o > I assume that you've just started with only keep-state for testing? We don't use limit rules at all, so it wasn't implemented. I think it will not so hard to implement. > I think flow names should be specified as an _optional_ parameter, thus= : >=20 > check-state [name] >=20 > keep-state [name] >=20 > limit {src-addr | src-port | dst-addr | dst-port} N [name] >=20 > where name (maybe flowname, for easier comprehension by man readers?) i= s=20 > optional, assigned as 'default' whenever omitted - as well as being for= =20 > backwards ruleset compatibility, which then only needs mentioning once,= =20 > and maybe also put another way in the STATEFUL FIREWALL section. >=20 > So a few of the existing example rules with no name could stand, while = > others (see below) append names of OUTBOUND and INBOUND or whatever. >=20 > As is, you have=20 >=20 > 740 .It Cm check-state Op Ar name | Cm any | Cm default >=20 > which in other contexts would mean you have to supply one of 'name' or = > 'any' or 'default' when you don't have to provide one, 'default' being = > assigned otherwise. Otherwise I think this is fairly well described. >=20 > Will 'ipfw -[e]d list|show' show the flow names? or the indices? It will show the flow name at the end of line. > As I pestered Lev about last year, we still need a small example rulese= t=20 > section that actually deals with potentially problematic stateful issue= s=20 > with NAT - which I still don't fully understand - beyond descriptions i= n=20 > the abstract case; ie an actual working dual- or multi-flow example. >=20 > I know these are "just doc" issues of little importance while testing=20 > working code, and I haven't supplied any patches, so are just FWIW .. Will try to implement support for limit rules and update man. Thanks. --=20 WBR, Andrey V. Elsukov --gTPAdF5CHc0LSPHQSOWlax3wDqkGDV1vX-- --xOITXn1oB5rwCOQoPtVqiPBUeh7J4aVPt Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXV/UzAAoJEAHF6gQQyKF6+O8H/26bc+g8wn0utsHj4Qo3Ldwu Z6FGtyitPds+UCaWVqpZxOFzYdoeQ8S97M/kbkYwn4/G6v1iBkW240pqsOZF5xX4 xjeheSPuR4UWUOtKsBc2k5YdIRnlpa8S7p49lCzSzGPaslsbOaGlZDy03+7iyU34 7MqdE4V+iEFa4bh5EqJAZe7ivBMKStsfrtZdByiq1UPNNUBe2I/mOeLkvOVb9rtO RKPai28I98wfxRFT655krQtYkAi5nWlSDUc0CpqPaQIsnZ7rVuGaQKiR/WMS63c0 xe4zGr/cOSkSQ3kZzVtKXCgktgrGUxDYh2DFGxnMilSLvoewrtVW68xVZwbwsBE= =bF8N -----END PGP SIGNATURE----- --xOITXn1oB5rwCOQoPtVqiPBUeh7J4aVPt-- From owner-freebsd-ipfw@freebsd.org Wed Jun 8 10:58:33 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DD9F9B6FF6B for ; Wed, 8 Jun 2016 10:58:33 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: from mail-vk0-x243.google.com (mail-vk0-x243.google.com [IPv6:2607:f8b0:400c:c05::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 96CBF1295; Wed, 8 Jun 2016 10:58:33 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: by mail-vk0-x243.google.com with SMTP id a126so672671vkb.1; Wed, 08 Jun 2016 03:58:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc; bh=MkIW7hQf7/DN2PUaVvVSRdcp0L6IrPHjUoBb0PUFH7g=; b=oTpZqu/cxUjsWstsXbAuCi3OEmrHVScu0cmSY1kC1o1qyU5VRa4uIGCrIjdR1ZBIO2 nGz+SKCHFSc2NwyAvkdJDnzUev7DZebsRHJhbSo3UV6t9M3d7n249C/c1qXPvrQTL8ox JZZ922MWSOFPXJhUYkQJJ0APb/GpkxVMAI/bawVBs7VpXM7EblzNQClEdIG8iTRZ1PWm hmPUtmqPMW2hkSN29HOafd771doIwB+PQ5woi5AjppUQdTPgqm1pCO8fNhuvzrT96PXf TZZirwshPWQSE+vbkMFsttHLPCAVuIyKmP+aPXCoOfQyTn1vUWL7nT1YdaY0mj6Ix48E llwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc; bh=MkIW7hQf7/DN2PUaVvVSRdcp0L6IrPHjUoBb0PUFH7g=; b=ksqqduexeIWGc9DZqugw1AOZbBb+ZEruU8YJ3wInQpc1xMoqulooU6rxjZ+1+3EsPz KUcaLTGIrBWHmyk7zdomtDLkyopv7SZhIGoOSSGVKhRgVhxv0NuB2IAyNO/nfIQi5M8o 3DX60cI39KIZRxtyJig4vIFar5yVH7jkYS1MQxozo+OI9v9IjBk+lmV1r3suzc/t+5ZA Oa0maMTo0Z263rNnS7caTzRvE+ZOaaCCHyHLC/ZF+hB7fOOszPdMvOfVSeo0ipT2/2z5 Qr+gp9auku7eA4MBYrb5j5CWJbeoWuG0rBnQcZbAdVWBGyuNoys2pFuOZgO4rJIBJZ6E pqJw== X-Gm-Message-State: ALyK8tJuWVe6TC+WwY4K/nxK66srhoCRO9DWpAvNVsMqQarik9lT2MUMxbwTrkYeoSRM0Z2l1YpgMkSoejlSsw== X-Received: by 10.31.167.84 with SMTP id q81mr1999292vke.51.1465383512612; Wed, 08 Jun 2016 03:58:32 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.37.69 with HTTP; Wed, 8 Jun 2016 03:58:32 -0700 (PDT) Reply-To: bycn82@dragonflybsd.org In-Reply-To: <5757F533.8070907@FreeBSD.org> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <20160607220136.R15883@sola.nimnet.asn.au> <5757F533.8070907@FreeBSD.org> From: Bill Yuan Date: Wed, 8 Jun 2016 18:58:32 +0800 Message-ID: Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: "Andrey V. Elsukov" Cc: Ian Smith , Julian Elischer , freebsd-ipfw , Lev Serebryakov , "Alexander V. Chernikov" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.22 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 10:58:34 -0000 In my opinion, keep-state == "if this kind of packet come again, we are going to perform the current action" check-state == "did we met this kind of packet before? Yes! then perform that action" so in DragonflyBSD, below commands are implemented to manipulate the "states" ipfw3 state show [rulenum] ipfw3 state add rule rulenum proto src:port dst:port [state-options] ipfw3 state delete rulenum On 8 June 2016 at 18:36, Andrey V. Elsukov wrote: > On 07.06.16 17:31, Ian Smith wrote: > > If your patch does what Lev wanted to achieve with (I thought too many) > > new dynamic rule actions, then I think your simpler solution is better, > > not least because it's far easier to understand for non-Julians :) > > > > Looking from a useability and documentation perspective only - I won't > > even be looking at this code - I have a few thoughts: > > > > Thus far, keep-state and limit seem to be interchangeable options; limit > > rules will need to work the same with respect to named dynamic flows; do > > I assume that you've just started with only keep-state for testing? > > We don't use limit rules at all, so it wasn't implemented. I think it > will not so hard to implement. > > > I think flow names should be specified as an _optional_ parameter, thus: > > > > check-state [name] > > > > keep-state [name] > > > > limit {src-addr | src-port | dst-addr | dst-port} N [name] > > > > where name (maybe flowname, for easier comprehension by man readers?) is > > optional, assigned as 'default' whenever omitted - as well as being for > > backwards ruleset compatibility, which then only needs mentioning once, > > and maybe also put another way in the STATEFUL FIREWALL section. > > > > So a few of the existing example rules with no name could stand, while > > others (see below) append names of OUTBOUND and INBOUND or whatever. > > > > As is, you have > > > > 740 .It Cm check-state Op Ar name | Cm any | Cm default > > > > which in other contexts would mean you have to supply one of 'name' or > > 'any' or 'default' when you don't have to provide one, 'default' being > > assigned otherwise. Otherwise I think this is fairly well described. > > > > Will 'ipfw -[e]d list|show' show the flow names? or the indices? > > It will show the flow name at the end of line. > > > As I pestered Lev about last year, we still need a small example ruleset > > section that actually deals with potentially problematic stateful issues > > with NAT - which I still don't fully understand - beyond descriptions in > > the abstract case; ie an actual working dual- or multi-flow example. > > > > I know these are "just doc" issues of little importance while testing > > working code, and I haven't supplied any patches, so are just FWIW .. > > Will try to implement support for limit rules and update man. Thanks. > > -- > WBR, Andrey V. Elsukov > > From owner-freebsd-ipfw@freebsd.org Wed Jun 8 13:04:39 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E6801B6EEAB for ; Wed, 8 Jun 2016 13:04:39 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id A2AA1134F for ; Wed, 8 Jun 2016 13:04:39 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-225-151.lns20.per1.internode.on.net [121.45.225.151]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id u58D4Yee031617 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 8 Jun 2016 06:04:37 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: freebsd-ipfw@freebsd.org References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> From: Julian Elischer Message-ID: <8771e387-6350-a4d7-860e-03e67b191174@freebsd.org> Date: Wed, 8 Jun 2016 21:04:25 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 13:04:40 -0000 On 7/06/2016 3:41 AM, Lev Serebryakov wrote: > I still hope to see https://reviews.freebsd.org/D1776 committed before > 11-RELEASE. > > It seems to me, that I does everything what was requested by reviewers. > > Pleeeeease? > I think I gave a blessing a long time ago.. you are blocked by melifaro I forget who he is in email or I'd send him one asking for some action. From owner-freebsd-ipfw@freebsd.org Thu Jun 9 21:11:12 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 248C5B70C6A for ; Thu, 9 Jun 2016 21:11:12 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id A60441797; Thu, 9 Jun 2016 21:11:11 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.1.107] (host81-147-143-168.range81-147.btcentralplus.com [81.147.143.168]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id DDA5B560; Fri, 10 Jun 2016 00:11:07 +0300 (MSK) Message-ID: <5759DB79.10205@FreeBSD.org> Date: Fri, 10 Jun 2016 00:11:21 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , freebsd-ipfw@freebsd.org CC: "Alexander V. Chernikov" , Julian Elischer Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> In-Reply-To: <5755F0D3.9060909@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 21:11:12 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 07.06.2016 00:53, Andrey V. Elsukov wrote: > looking at provided description and examples, seems the main task > you want to solve is problem with NAT. But from my point of view, > you are trying to solve it in a easy way wrongly using existing > methods. It is was initial driver for this patch, yes, but, please, read subject (? is mistype, of course, it is closing "). Current set of primitives, dealing with state, is terribly wrong, IMHO. "keep-state" which trigger (any!) state check alone is awuful, and complete "keep-state / check-state" pair is ugly hack. It is like CISC vs RISC, actually. New primitives are ORTHOGONAL. Each one solves one and only one well-defined task, state creation, state checking and command execution are well-separated. IMHO, "keep-state" in it current form should be killed with fire. Yes, I understand about backward compatibility and POLA, so I don't propose to really remove it, but, IMHO, new set is much, much better. > As you described in patch to ipfw(8) "Problem is, you need to > create dynamic rule before NAT and check it after NAT actions (or > vice versa) to have consistent addresses and ports." It is only very rudimentary example to show the point of new primitives. All meaningful examples require big and complex rulesets, really. > In terms of ipfw(4) a state is represented by ipfw_flow_id > structure. To solve your task you just needs two states - one for > not translated flow and second - for translated. For what?! Logically it is one flow. NAT is kludge itself, of course, but, IMHO, logically it doesn't create new flow, or connection, whatever your name it. It hacks existing one. > Due to limits of implementation this looks impossible to solve. But > proposed patch with deferred action looks too hackish to me. IMHO, it untangles current very sad situation. > With the following patch you will be able create two different > states, I think, and solve your task with NAT and dynamic rules: > https://reviews.freebsd.org/D6674 Named states are great and very useful by themselves, but how this solve problem, that "keep-state" implies "check-state" rule, for example ? I seen a thousand posts, messages and how-tos about stateful IPFW and all of them suffer from this "keep-state is check-state" problem, really, when you try to structure your firewall in "ingress / egress" per-interface sections and not one small ruleset for one interface. - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJXWdt4XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePQ+kP/jTUZQ/W2srUhiRCkTzDsGpy dbODp6utMjQGwtZKgPRVN4+0KuchgJInA6odB/34WKfgW5THpevLkh5do8QGvm+5 /8DcYZOYwCk45TRkjhctBH6u2t0v3TPvjd1pPkknmhd3qE9Zzkk2fi+0iUWBavMH LvLJ+afUlmw8l95Om8g4Per3C7TEWmxXews3k+vg1xgrTtPn6m1Vcwspp7gHe2Zo OIGTzDl0S95SUofQuQX3vD7gPqm6YTnRVhtHrb36saVpP2HCv6e+7vOkyfiTV4nd Mchu3T6e9zJ2cmWBRIE9d/wB18LRVjWE+pvosTf6EEIkRJnUUnCZF19EJj8BS+9X 7+zbPnVeUSo17YdxSTcDXL0cBuzRIsz50V2Q6bFgl313PB9u97a4FeLdNmqEZfnN jEgeonc8loN6Fw/Mgjdn2wjmAhZaWU+zCpozzDPcjevkl9NIVVkMys4iZUUCdRkG yGQtU18X3hHwrbM4uJs7K9JLJj1HHEgpT9mnZ3qxCQ1YKEWZ0plgPvXoFWOiYYIB Ecz19D/kLBad3gVZ0X9NZwqA2XM23UmfMiKqd0ZcoOPiMY1WY35PQWOocOhiCIW4 mhcEwp9ZR2mV7OZEO1ObLiK1Jo/q0xNn2eV9UgSrYJGSjOSLPj+9rC2zOjBbO1EO o1H+cNxLn5zMM4sybo9X =WZgr -----END PGP SIGNATURE----- From owner-freebsd-ipfw@freebsd.org Fri Jun 10 08:07:33 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9C862AEE734 for ; Fri, 10 Jun 2016 08:07:33 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx2.freebsd.org", Issuer "Gandi Standard SSL CA 2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88C3412A6; Fri, 10 Jun 2016 08:07:33 +0000 (UTC) (envelope-from ae@FreeBSD.org) Received: from butcher-nb.yandex.net (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id CD18165FC5; Fri, 10 Jun 2016 08:07:31 +0000 (UTC) (envelope-from ae@FreeBSD.org) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: lev@FreeBSD.org, freebsd-ipfw@freebsd.org References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> Cc: "Alexander V. Chernikov" , Julian Elischer From: "Andrey V. Elsukov" Message-ID: <575A752B.1070304@FreeBSD.org> Date: Fri, 10 Jun 2016 11:07:07 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1 MIME-Version: 1.0 In-Reply-To: <5759DB79.10205@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Ml6vIscK6hcDbfoErNl1LwSqABb1dgS0J" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 08:07:33 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Ml6vIscK6hcDbfoErNl1LwSqABb1dgS0J Content-Type: multipart/mixed; boundary="PJ03SWWUvkVl2H2ST3SEvVeDBRFPBhegA" From: "Andrey V. Elsukov" To: lev@FreeBSD.org, freebsd-ipfw@freebsd.org Cc: "Alexander V. Chernikov" , Julian Elischer Message-ID: <575A752B.1070304@FreeBSD.org> Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> In-Reply-To: <5759DB79.10205@FreeBSD.org> --PJ03SWWUvkVl2H2ST3SEvVeDBRFPBhegA Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 10.06.16 00:11, Lev Serebryakov wrote: >> In terms of ipfw(4) a state is represented by ipfw_flow_id >> structure. To solve your task you just needs two states - one for >> not translated flow and second - for translated. > For what?! Logically it is one flow. NAT is kludge itself, of > course, but, IMHO, logically it doesn't create new flow, or > connection, whatever your name it. It hacks existing one. Your patch does exactly what I said - it creates state for untranslated flow when you call record-state with deferred action. Then after translation this flow has new addresses and ports, so ipfw_install_or_update_state() will create new state, old state will not updated (don't know for what purpose you have renamed it). Then when check-state/probe-state will be checked, both states can be updated by lookup_dyn_rule_locked() depending from flow that triggers this opcode. So, you introduced new implicit behavior while thinking that resolve old wrong behavior. --=20 WBR, Andrey V. Elsukov --PJ03SWWUvkVl2H2ST3SEvVeDBRFPBhegA-- --Ml6vIscK6hcDbfoErNl1LwSqABb1dgS0J Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCAAGBQJXWnUrAAoJEAHF6gQQyKF6z0YH/R49oAqK6nAUKwkTbnl2VBCs R3dLkcuVQggMGFuNH0YLQ5NJ2Swny3nHqU2opM2QY75HKYC+B1+yTJu2BJ/6dN61 Gqn7l9XQta7pkiDMvuYVFlHuf0UX4eCzWZYuWZpk4mqxLqPjO/eDUKxYffVXSsTV anLcQVOHx8hNMMgpzXoOsKIXOyYPqtCQkbXld+nkVuOlYN3pdsYYIXnlbNMU8w58 8l8gGsp4Vqhi4yAkk7aNTpmh+mDi1vHOZkFLXopH7tlevLNZRbvrr5sioSmOhTvs RCp4YIXAWmpds4FNA+srpZ1Ep9L+uUfdcOdDeOCZ6+zdM+UDtLtJP60rP4/xZWQ= =1Q3D -----END PGP SIGNATURE----- --Ml6vIscK6hcDbfoErNl1LwSqABb1dgS0J-- From owner-freebsd-ipfw@freebsd.org Sat Jun 11 09:40:26 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9525AEF0A7 for ; Sat, 11 Jun 2016 09:40:26 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:201:6350::2]) by mx1.freebsd.org (Postfix) with ESMTP id 7869C2A13; Sat, 11 Jun 2016 09:40:26 +0000 (UTC) (envelope-from lev@FreeBSD.org) Received: from [192.168.0.23] (cpc92320-cmbg19-2-0-cust1479.5-4.cable.virginm.net [82.13.69.200]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 2B03C7C1; Sat, 11 Jun 2016 12:40:24 +0300 (MSK) Message-ID: <575BDC9A.8000105@FreeBSD.org> Date: Sat, 11 Jun 2016 12:40:42 +0300 From: Lev Serebryakov Reply-To: lev@FreeBSD.org Organization: FreeBSD User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: "Andrey V. Elsukov" , freebsd-ipfw@freebsd.org CC: "Alexander V. Chernikov" , Julian Elischer Subject: Re: IPFW: more "orthogonal? state operations, push into 11? References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <575A752B.1070304@FreeBSD.org> In-Reply-To: <575A752B.1070304@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 11 Jun 2016 09:40:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 10.06.2016 11:07, Andrey V. Elsukov wrote: >>> In terms of ipfw(4) a state is represented by ipfw_flow_id >>> structure. To solve your task you just needs two states - one >>> for not translated flow and second - for translated. >> For what?! Logically it is one flow. NAT is kludge itself, of >> course, but, IMHO, logically it doesn't create new flow, or >> connection, whatever your name it. It hacks existing one. > > Your patch does exactly what I said - it creates state for > untranslated flow when you call record-state with deferred action. > Then after translation this flow has new addresses and ports, so > ipfw_install_or_update_state() will create new state, old state > will not updated (don't know for what purpose you have renamed > it). Why will ipfw_install_or_update_state() be called after translation with my patch and example? I'm using my patch more than year, and I don't have any problems with splitting of states or expiration of "right" ones, and I've checked dynamic states very carefully first several days after patch was complete (and I had problems with rules expiration in very first, unpublished, version of my patch). > Then when check-state/probe-state will be checked, both states can > be updated by lookup_dyn_rule_locked() depending from flow that > triggers this opcode. So, you introduced new implicit behavior > while thinking that resolve old wrong behavior. Sorry, I lost you here. Why untranslated flow will trigger check opcode? It will be mistake in ruleset, for sure! - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJXW9yaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePIKEP/jPPXByu7ufxZhoK7LJ7SY4Q VEmbrQ+FXvtwkQEHCLVeAPYjOkELVhyM+Z+mJijx4cnYibvmzS1Eh1pPYvsanios x3iec4rz86wli53rhxh19hzWRzmKAXHiw3xd+eIjvlgnIx+TTresn1fNeudVPpwU /iGlehzwAxaZXctjsQkwqJolZLtb8iy98OHE0W/Maj0sjJNj+4b6Cn52oi5Z70V4 DlJ5SbKpUr7NHRCLidA5YxLDQ2MHJimBHh/zoSisU7DmsvrQiJ8ETF5A6b9QFQNV WmKlrd3N+biXF2kXpq9fjTRet0BMhfLgkZk+l/GaY6vJ8C5k0cQuh1GD5ZbJ23D3 mgdE41LFX/m7iXpdc0DoKW8nF8yVJsgYvxnaIKN+i7VVKBp4MUIhsdF66k7KUewB /IHH3kPMdIBleQgfO92QLomCTyD0s31MqclPq3bm+AfI94ZuJonN2YSzgkO1HwXF 0xCsR9C/PxM7AYtiF9QEuaUOr/gVPZQUJlvUcJ2Lh2r9vsEB35qGkAuPTAZwufI7 nzeFNKiSJxv/PL3YmL1qHEQNHqdvt8OdaJ+IZacNl7PfnGsQ76P3O9BTj6QWGAAS 1uxW1qZGp2hcAbv1J5ctNOG9OFNLP7mnVTMIIoX9Ze8FITibJDo5pLfIMJuJv4cy F6G6phqgAAckRcOm3ab3 =fjEL -----END PGP SIGNATURE-----