From owner-freebsd-ipfw@FreeBSD.ORG Mon Feb 2 18:12:50 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4E19D2D7 for ; Mon, 2 Feb 2015 18:12:50 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 10591C8C for ; Mon, 2 Feb 2015 18:12:50 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 06A245C003 for ; Mon, 2 Feb 2015 21:12:08 +0300 (MSK) Message-ID: <54CFBDF7.30301@FreeBSD.org> Date: Mon, 02 Feb 2015 21:12:07 +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.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: How to configure nat for interface which will be created later? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:12:50 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 It is possible to use non-existing interface name in via / xmit / recv option. It allows to write firewall which works with, say, VPN connection which is created AFTER firewall is loaded on boot. But "nat X config if " doesn't allow to use non-existing interface name! It looks like very strict limitation, as it doesn't allow to include VPN to nat config! Is here any solution for this problem? - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUz733XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePiT0P/A0QqEQD3vNBJYPvOEZwW2Vc 4xVlmMbqN0n/Wz+0bN/v8cIa5gMAYSwRGSyvE9D8FsbN7eXBe2J1DUjEq7E7er7E +jsr+bQTMpblvVBxCig+bNyjnDbFSqFzlU6ZyeBvYXbuhGmeaSnwAbfrl2eTGJ5X RlYjWRMmsUcJf+xp8xLifWoNC99/a4dyjTcmNiUd7ByrYVnnuriVCuM/NFRJPApS f2RUfoBhblDF9bC0NvnheIJpJ6sK12ZCTH4oRfRW4VEaKBpjpygH3WqmGqTUas9C rOEpE7HUA7LjwFqhi2TGbreZZX4EFVztWOUi9ufKoHX93264rtIv8EMu/LtKjuyy LrbBDl5zH6A881eTrQdZXjsG87VSwZA3ctlPjg/trw8UX0qtG3MsbfgIgp47srVK gMKmVMt0kpzHs3n7rmk8On5ELwUkbjMOPFsg1JXfhNUGelJJ+pMXBm0kaIpiHdzT 6tkSgfrvOJEziFmDF5hCcfHPzMGXJqiMCFqvrX7IsEmx9VLsLKVs2NoX7D+yu4T/ /+SAffJ4OMC22SyDHpaSfZLZTN1eHquepnpvGWYo7aUJm0kQ15Wp8qTMqQ4MFPMz GFoOuJdPDqhd96aTKYI+UYYRC51lqyCiJxmETqMWOgeT3muVsya2PRrVYALEy38H enNnWTWHiw2+3HMWMhtl =V2ZH -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Mon Feb 2 18:20:10 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6D8614A4 for ; Mon, 2 Feb 2015 18:20:10 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 2DF62CEB for ; Mon, 2 Feb 2015 18:20:10 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 61CB25C002 for ; Mon, 2 Feb 2015 21:19:39 +0300 (MSK) Message-ID: <54CFBFB9.9040801@FreeBSD.org> Date: Mon, 02 Feb 2015 21:19:37 +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.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Re: How to configure nat for interface which will be created later? References: <54CFBDF7.30301@FreeBSD.org> In-Reply-To: <54CFBDF7.30301@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 18:20:10 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02.02.2015 21:12, Lev Serebryakov wrote: > It is possible to use non-existing interface name in via / xmit / > recv option. It allows to write firewall which works with, say, > VPN connection which is created AFTER firewall is loaded on boot. > > But "nat X config if " doesn't allow to use non-existing > interface name! It looks like very strict limitation, as it > doesn't allow to include VPN to nat config! > > Is here any solution for this problem? Looking at "sbin/ipfw/nat.c:166" and "sys/netpfil/ipfw/ip_fw_nat.c", it looks like this userland check is too restrictive. But I'm not sure, that I'm right... - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUz7+5XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePL6kP/2CFIvPrqGhYISH1z420qAoK r5oE5SwlFcwARQONqUuizTsmlqt4UIP8xWGxb7YWzQgkbXVlht1zgBvby3xVzlJo zoXfSsz9CN3GJShBkuCcXG0pHh1UpFrFYR1RN8uLHvsm6i+Hq5nZuaBSio+eaD1+ x/TmLdz+zVmQGO6GWscnN21A0bRP49Q4KJKZlkklAhZ0xVU9QQ77Mc3vCMOk0dGA ObAeFu8fWqQHVGCeQppxJkLynWrhnHyyTeJvEvewGC+aWCu9H4xxa5oTEKFytQWc ImQcfzkqgnk5U1gPsND89RXp8gxqWzV9TbRXF7cV2hHFbs4inJAUw+n2ammM4iFR xg2BJlSxcaCx2xYtERqSRT6MRFR1zI1q/hEOW6puyJ611ILQ+TQRp5zrhnY1RkSe qtVrpgtchJsFK1759PreVqd6dAbmfjhnklgdoL6J6r+LjNpEOI+2t0O+4sudG0M3 T1unH0K8IcdRg67LYJW371pUn5V4qIhnur8YXuXp24vuHvDZQmhZRdRDrpfESl+s f97H06jGA9FIRS05o0PMIGUtpI48S7XjoaobOcb1CjVTfyItWMjAvK7TkpF1zmxD z8AOdpHDZezf/TVDGKNxBLrQzK9hMOoUz9PKQA7JkbfDHmT6/zwDTBYnNjSW+VuS ExLECR6f/seC3nEW6tek =Vyhu -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Mon Feb 2 19:17:38 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 47C7724F; Mon, 2 Feb 2015 19:17:38 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id DA68665B; Mon, 2 Feb 2015 19:17:37 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id EDCAE5C002; Mon, 2 Feb 2015 22:17:26 +0300 (MSK) Message-ID: <54CFCD45.9070304@FreeBSD.org> Date: Mon, 02 Feb 2015 22:17:25 +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.4.0 MIME-Version: 1.0 To: freebsd-ipfw , freebsd-net Subject: [RFC][patch] Two new actions: state-allow and state-deny Content-Type: multipart/mixed; boundary="------------040906070105090005040205" X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 19:17:38 -0000 This is a multi-part message in MIME format. --------------040906070105090005040205 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Now to make stateful firewall with NAT you need to make some not very "readable" tricks to record state ("allow") of outbound connection before NAT, but pass packet to NAT after that. I know two: (a) skipto-nat-allow pattern from many HOWOTOs add 1000 skipto 2000 all from any to any out xmit outIface add 1010 skipto 3000 all from any to any in recv outIface add 2000 skipto 2010 from any to any keep-state add 2010 nat NR from any to any out // Note this "out" in out section! add 2020 allow all from any to any add 3000 nat NR from any to any add 3010 check-state // Use dynamic rule based on 2000 (b) Adding "allow keep-state" to _IN_ rules on _internal_ interfaces to check this states AFTER _IN_ nat on _external_ interfaces. I don't like both of them. First one is not very clear and needs additional "out" option on outbound NAT rule. Second one requires to have "allow keep-state" and "check-state" rules in different parts of firewall, on different interfaces, which is not very clear too and needs additional conditions for "allow keep-state" if you don't want stateful firewall for internal networks and only want states for external traffic. I propose two new actions: state-allow and state-deny. They imply "keep-state" and create new dynamic rules, when called directly, but pass packet to NEXT rule after that (don't stop search). When they are called as dynamic rule, they acts as "allow" and "deny". So, stateful firewall with NAT could be rewritten like this: add 1000 skipto 2000 all from any to any out xmit outIface add 1010 skipto 3000 all from any to any in recv outIface add 2000 state-allow from any to any // keep-state is implied add 2010 nat NR from any to any // No "out" here! add 2020 allow all from any to any add 3000 nat NR from any to any add 3010 check-state // Use dynamic rule based on 2000 as "allow" here What do you think? - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUz81EXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePkhwQAJg4s1Ipomi0lZTqa8pklExD GHvkeuVdm1RSakolwHf8M26a+Xg1zlIm0tD2PQ18FkaA1QTjwai7kyKu2SwhsvkF P7B3GE33Pj4dhMzhpnmSnxcjLZEAENENzAOnGBN47NM617KOkJmyRmH54RO8xFI8 UbctlfiWC0ECujlWC4HcLthlrI3ZemqeFK1llzQ+k0LgUDQ8eegFmrLCbMVbVKxJ 4HACPQzzPwzabZE+kifE1KDnOEthEuTXuMpL6pS98s8w+b92TFJsS40DqngWNuqv M2QCCJbLZRwoDRTkf3H8AlbdIk94CPFjJkmZd86ZUpKF3rVJ7VICH7SkV90P1hlm yRc/26jX2LvqyyKgxMDQ4UpJuSikxASHx/3mDOV83snxlXtwW0or6f+XSW1QVFFt 2OCo6DmwclQ2HzBaomy0QKqlKq09VzHJdEBtfsyBqKyQP2UG3/CDj6rwqc564rOb MDJFDtsMsquOgJTBSYLcAQhc8v9I3HUuELT/eyo3YCCrPKAAPtV89jWZ2dI+np3h utaVJxJ4qSyVp5R3H2MTvWdk1PPptygxx0UHMVyNTgSnsbczNsywWzELoOzTzEZn XS352D2dWXsvFV07cwtHovnY+vCKOXVI2ljJ6uHwZZlisJg4M+o80LChHT5jQ6nw 9DVWmu2YK6nC7aJI6Fy7 =TMJo -----END PGP SIGNATURE----- --------------040906070105090005040205 Content-Type: text/plain; charset=windows-1251; name="ipfw-state-actions.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-actions.diff" SW5kZXg6IHNiaW4vaXBmdy9pcGZ3LjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3L2lw ZncuOAkocmV2aXNpb24gMjc4MDIxKQorKysgc2Jpbi9pcGZ3L2lwZncuOAkod29ya2luZyBj b3B5KQpAQCAtOTMyLDYgKzkzMiwyNiBAQAogLkVkCiAuUHAKIFRoaXMgY29zbWV0aWMgYW5u b3lhbmNlIG1heSBiZSBmaXhlZCBpbiBmdXR1cmUgcmVsZWFzZXMuCisuSXQgQ20gc3RhdGUt YWxsb3cKK0NyZWF0ZSBkeW5hbWljIHJ1bGUgd2hpY2ggYWN0cyBhcworLkNtIGFsbG93City dWxlIHdoZW4gY2hlY2tlZCB3aXRoCisuQ20gY2hlY2stc3RhdGUKK2FjdGlvbi4KK1doZW4g dGhpcyBhY3Rpb24gaXMgdGFrZW4gZGlyZWN0bHksIHNlYXJjaCBjb250aW51ZXMgd2l0aCB0 aGUgbmV4dCBydWxlLgorVGhpcyBhY3Rpb24gaW1wbGllcworLkNtIGtlZXAtc3RhdGUKK2lu c3RydWN0aW9uLgorLkl0IENtIHN0YXRlLWRlbnkKK0NyZWF0ZSBkeW5hbWljIHJ1bGUgd2hp Y2ggYWN0cyBhcworLkNtIGRlbnkKK3J1bGUgd2hlbiBjaGVja2VkIHdpdGgKKy5DbSBjaGVj ay1zdGF0ZQorYWN0aW9uLgorV2hlbiB0aGlzIGFjdGlvbiBpcyB0YWtlbiBkaXJlY3RseSwg c2VhcmNoIGNvbnRpbnVlcyB3aXRoIHRoZSBuZXh0IHJ1bGUuCitUaGlzIGFjdGlvbiBpbXBs aWVzCisuQ20ga2VlcC1zdGF0ZQoraW5zdHJ1Y3Rpb24uCiAuSXQgQ20gdGVlIEFyIHBvcnQK IFNlbmQgYSBjb3B5IG9mIHBhY2tldHMgbWF0Y2hpbmcgdGhpcyBydWxlIHRvIHRoZQogLlhy IGRpdmVydCA0CkluZGV4OiBzYmluL2lwZncvaXBmdzIuYwo9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBz YmluL2lwZncvaXBmdzIuYwkocmV2aXNpb24gMjc4MDIxKQorKysgc2Jpbi9pcGZ3L2lwZncy LmMJKHdvcmtpbmcgY29weSkKQEAgLTI2NCw2ICsyNjQsMTIgQEAKIAl7ICJzZXRkc2NwIiwJ CVRPS19TRVREU0NQIH0sCiAJeyAiY2FsbCIsCQlUT0tfQ0FMTCB9LAogCXsgInJldHVybiIs CQlUT0tfUkVUVVJOIH0sCisJeyAic3RhdGUtYWNjZXB0IiwJVE9LX1NUQVRFX0FDQ0VQVCB9 LAorCXsgInN0YXRlLXBhc3MiLAkJVE9LX1NUQVRFX0FDQ0VQVCB9LAorCXsgInN0YXRlLWFs bG93IiwJVE9LX1NUQVRFX0FDQ0VQVCB9LAorCXsgInN0YXRlLXBlcm1pdCIsCVRPS19TVEFU RV9BQ0NFUFQgfSwKKwl7ICJzdGF0ZS1kZW55IiwJCVRPS19TVEFURV9ERU5ZIH0sCisJeyAi c3RhdGUtZHJvcCIsCQlUT0tfU1RBVEVfREVOWSB9LAogCXsgTlVMTCwgMCB9CS8qIHRlcm1p bmF0b3IgKi8KIH07CiAKQEAgLTE1ODQsNiArMTU5MCwxNCBAQAogCQkJCWJwcmludF91aW50 X2FyZyhicCwgImNhbGwgIiwgY21kLT5hcmcxKTsKIAkJCWJyZWFrOwogCisJCWNhc2UgT19T VEFURV9BQ0NFUFQ6CisJCQlicHJpbnRmKGJwLCAic3RhdGUtYWxsb3ciKTsKKwkJCWJyZWFr OworCisJCWNhc2UgT19TVEFURV9ERU5ZOgorCQkJYnByaW50ZihicCwgInN0YXRlLWRlbnki KTsKKwkJCWJyZWFrOworCiAJCWRlZmF1bHQ6CiAJCQlicHJpbnRmKGJwLCAiKiogdW5yZWNv Z25pemVkIGFjdGlvbiAlZCBsZW4gJWQgIiwKIAkJCQljbWQtPm9wY29kZSwgY21kLT5sZW4p OwpAQCAtMzgwNyw2ICszODIxLDE2IEBACiAJCWZpbGxfY21kKGFjdGlvbiwgT19DQUxMUkVU VVJOLCBGX05PVCwgMCk7CiAJCWJyZWFrOwogCisJY2FzZSBUT0tfU1RBVEVfQUNDRVBUOgor CQloYXZlX3N0YXRlID0gYWN0aW9uOworCQlhY3Rpb24tPm9wY29kZSA9IE9fU1RBVEVfQUND RVBUOworCQlicmVhazsKKworCWNhc2UgVE9LX1NUQVRFX0RFTlk6CisJCWhhdmVfc3RhdGUg PSBhY3Rpb247CisJCWFjdGlvbi0+b3Bjb2RlID0gT19TVEFURV9ERU5ZOworCQlicmVhazsK KwogCWRlZmF1bHQ6CiAJCWVycngoRVhfREFUQUVSUiwgImludmFsaWQgYWN0aW9uICVzXG4i LCBhdlstMV0pOwogCX0KQEAgLTM4OTgsNyArMzkyMiw3IEBACiAJCWNtZCA9IG5leHRfY21k KGNtZCwgJmNibGVuKTsKIAl9CiAKLQlpZiAoaGF2ZV9zdGF0ZSkJLyogbXVzdCBiZSBhIGNo ZWNrLXN0YXRlLCB3ZSBhcmUgZG9uZSAqLworCWlmIChoYXZlX3N0YXRlICYmIGhhdmVfc3Rh dGUtPm9wY29kZSA9PSBUT0tfQ0hFQ0tTVEFURSkJLyogY2hlY2stc3RhdGUsIHdlIGFyZSBk b25lICovCiAJCWdvdG8gZG9uZTsKIAogI2RlZmluZSBPUl9TVEFSVCh0YXJnZXQpCQkJCQlc CkBAIC00NTgwLDcgKzQ2MDQsOSBAQAogCS8qCiAJICogZ2VuZXJhdGUgT19QUk9CRV9TVEFU RSBpZiBuZWNlc3NhcnkKIAkgKi8KLQlpZiAoaGF2ZV9zdGF0ZSAmJiBoYXZlX3N0YXRlLT5v cGNvZGUgIT0gT19DSEVDS19TVEFURSkgeworCWlmIChoYXZlX3N0YXRlICYmIGhhdmVfc3Rh dGUtPm9wY29kZSAhPSBPX0NIRUNLX1NUQVRFICYmCisJICAgIGhhdmVfc3RhdGUtPm9wY29k ZSAhPSBPX1NUQVRFX0FDQ0VQVCAmJgorCSAgICBoYXZlX3N0YXRlLT5vcGNvZGUgIT0gT19T VEFURV9ERU5ZKSB7CiAJCWZpbGxfY21kKGRzdCwgT19QUk9CRV9TVEFURSwgMCwgMCk7CiAJ CWRzdCA9IG5leHRfY21kKGRzdCwgJnJibGVuKTsKIAl9CkBAIC00NjA2LDcgKzQ2MzIsOSBA QAogCS8qCiAJICogcHV0IGJhY2sgdGhlIGhhdmVfc3RhdGUgY29tbWFuZCBhcyBsYXN0IG9w Y29kZQogCSAqLwotCWlmIChoYXZlX3N0YXRlICYmIGhhdmVfc3RhdGUtPm9wY29kZSAhPSBP X0NIRUNLX1NUQVRFKSB7CisJaWYgKGhhdmVfc3RhdGUgJiYgaGF2ZV9zdGF0ZS0+b3Bjb2Rl ICE9IE9fQ0hFQ0tfU1RBVEUgJiYKKwkgICAgaGF2ZV9zdGF0ZS0+b3Bjb2RlICE9IE9fU1RB VEVfQUNDRVBUICYmCisJICAgIGhhdmVfc3RhdGUtPm9wY29kZSAhPSBPX1NUQVRFX0RFTlkp IHsKIAkJaSA9IEZfTEVOKGhhdmVfc3RhdGUpOwogCQlDSEVDS19SQlVGTEVOKGkpOwogCQli Y29weShoYXZlX3N0YXRlLCBkc3QsIGkgKiBzaXplb2YodWludDMyX3QpKTsKSW5kZXg6IHNi aW4vaXBmdy9pcGZ3Mi5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHNiaW4vaXBmdy9pcGZ3Mi5oCShy ZXZpc2lvbiAyNzgwMjEpCisrKyBzYmluL2lwZncvaXBmdzIuaAkod29ya2luZyBjb3B5KQpA QCAtMTAzLDYgKzEwMyw4IEBACiAJVE9LX1JFQVNTLAogCVRPS19DQUxMLAogCVRPS19SRVRV Uk4sCisJVE9LX1NUQVRFX0FDQ0VQVCwKKwlUT0tfU1RBVEVfREVOWSwKIAogCVRPS19BTFRR LAogCVRPS19MT0csCkluZGV4OiBzeXMvbmV0aW5ldC9pcF9mdy5oCj09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0K LS0tIHN5cy9uZXRpbmV0L2lwX2Z3LmgJKHJldmlzaW9uIDI3ODAyMSkKKysrIHN5cy9uZXRp bmV0L2lwX2Z3LmgJKHdvcmtpbmcgY29weSkKQEAgLTI1Myw2ICsyNTMsOSBAQAogCU9fU0VU RFNDUCwJCS8qIGFyZzE9RFNDUCB2YWx1ZSAqLwogCU9fSVBfRkxPV19MT09LVVAsCS8qIGFy ZzE9dGFibGUgbnVtYmVyLCB1MzI9dmFsdWUJKi8KIAorCU9fU1RBVEVfQUNDRVBULAkJLyog bm9uZQkJCQkqLworCU9fU1RBVEVfREVOWSwJCS8qIG5vbmUgCQkJKi8KKwogCU9fTEFTVF9P UENPREUJCS8qIG5vdCBhbiBvcGNvZGUhCQkqLwogfTsKIApJbmRleDogc3lzL25ldHBmaWwv aXBmdy9pcF9mdzIuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3 Mi5jCShyZXZpc2lvbiAyNzgwMjEpCisrKyBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3Mi5jCSh3 b3JraW5nIGNvcHkpCkBAIC0xODU2LDcgKzE4NTYsNyBAQAogCiAJCQljYXNlIE9fTE9HOgog CQkJCWlwZndfbG9nKGNoYWluLCBmLCBobGVuLCBhcmdzLCBtLAotCQkJCSAgICBvaWYsIG9m ZnNldCB8IGlwNmZfbWYsIHRhYmxlYXJnLCBpcCk7CisJCQkJICAgIG9pZiwgb2Zmc2V0IHwg aXA2Zl9tZiwgdGFibGVhcmcsIGlwLCBxKTsKIAkJCQltYXRjaCA9IDE7CiAJCQkJYnJlYWs7 CiAKQEAgLTIxODgsNyArMjE4OCw3IEBACiAJCQkJYnJlYWs7CiAKIAkJCWNhc2UgT19BQ0NF UFQ6Ci0JCQkJcmV0dmFsID0gMDsJLyogYWNjZXB0ICovCisJCQkJcmV0dmFsID0gSVBfRldf UEFTUzsJLyogYWNjZXB0ICovCiAJCQkJbCA9IDA7CQkvKiBleGl0IGlubmVyIGxvb3AgKi8K IAkJCQlkb25lID0gMTsJLyogZXhpdCBvdXRlciBsb29wICovCiAJCQkJYnJlYWs7CkBAIC0y NTM4LDYgKzI1MzgsMjQgQEAKIAkJCQlicmVhazsKIAkJCX0KIAorCQkJY2FzZSBPX1NUQVRF X0FDQ0VQVDoKKwkJCWNhc2UgT19TVEFURV9ERU5ZOiB7CisJCQkJbCA9IDA7CS8qIGluIGFu eSBjYXNlIGV4aXQgaW5uZXIgbG9vcCAqLworCQkJCWlmIChxID09IE5VTEwgfHwgcS0+cnVs ZSAhPSBmKSB7CisJCQkJCWlmIChpcGZ3X2luc3RhbGxfc3RhdGUoY2hhaW4sIGYsCisJCQkJ CSAgICAoaXBmd19pbnNuX2xpbWl0ICopY21kLCBhcmdzLCB0YWJsZWFyZykpIHsKKwkJCQkJ CS8qIGVycm9yIG9yIGxpbWl0IHZpb2xhdGlvbiAqLworCQkJCQkJcmV0dmFsID0gSVBfRldf REVOWTsKKwkJCQkJCWRvbmUgPSAxOyAvKiBleGl0IG91dGVyIGxvb3AgKi8KKwkJCQkJfQor CQkJCX0gZWxzZSB7CisJCQkJCXJldHZhbCA9IGNtZC0+b3Bjb2RlID09IE9fU1RBVEVfQUND RVBUID8KKwkJCQkJICAgIElQX0ZXX1BBU1MgOiBJUF9GV19ERU5ZOworCQkJCQlkb25lID0g MTsJLyogZXhpdCBvdXRlciBsb29wICovCisJCQkJfQorCQkJCWJyZWFrOworCQkJfQorCiAJ CQlkZWZhdWx0OgogCQkJCXBhbmljKCItLSB1bmtub3duIG9wY29kZSAlZFxuIiwgY21kLT5v cGNvZGUpOwogCQkJfSAvKiBlbmQgb2Ygc3dpdGNoKCkgb24gb3Bjb2RlcyAqLwpJbmRleDog c3lzL25ldHBmaWwvaXBmdy9pcF9md19keW5hbWljLmMKPT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lz L25ldHBmaWwvaXBmdy9pcF9md19keW5hbWljLmMJKHJldmlzaW9uIDI3ODAyMSkKKysrIHN5 cy9uZXRwZmlsL2lwZncvaXBfZndfZHluYW1pYy5jCSh3b3JraW5nIGNvcHkpCkBAIC03MDgs NiArNzA4LDggQEAKIAogCXN3aXRjaCAoY21kLT5vLm9wY29kZSkgewogCWNhc2UgT19LRUVQ X1NUQVRFOgkvKiBiaWRpciBydWxlICovCisJY2FzZSBPX1NUQVRFX0FMTE9XOgorCWNhc2Ug T19TVEFURV9ERU5ZOgogCQlxID0gYWRkX2R5bl9ydWxlKCZhcmdzLT5mX2lkLCBpLCBPX0tF RVBfU1RBVEUsIHJ1bGUpOwogCQlicmVhazsKIApJbmRleDogc3lzL25ldHBmaWwvaXBmdy9p cF9md19sb2cuYwo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09Ci0tLSBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X2xv Zy5jCShyZXZpc2lvbiAyNzgwMjEpCisrKyBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X2xvZy5j CSh3b3JraW5nIGNvcHkpCkBAIC0yNDgsNyArMjQ4LDcgQEAKIHZvaWQKIGlwZndfbG9nKHN0 cnVjdCBpcF9md19jaGFpbiAqY2hhaW4sIHN0cnVjdCBpcF9mdyAqZiwgdV9pbnQgaGxlbiwK ICAgICBzdHJ1Y3QgaXBfZndfYXJncyAqYXJncywgc3RydWN0IG1idWYgKm0sIHN0cnVjdCBp Zm5ldCAqb2lmLAotICAgIHVfc2hvcnQgb2Zmc2V0LCB1aW50MzJfdCB0YWJsZWFyZywgc3Ry dWN0IGlwICppcCkKKyAgICB1X3Nob3J0IG9mZnNldCwgdWludDMyX3QgdGFibGVhcmcsIHN0 cnVjdCBpcCAqaXAsIGlwZndfZHluX3J1bGUgKnEpCiB7CiAJY2hhciAqYWN0aW9uOwogCWlu dCBsaW1pdF9yZWFjaGVkID0gMDsKQEAgLTQxOSw2ICs0MTksMTggQEAKIAkJCQlzbnByaW50 ZihTTlBBUkdTKGFjdGlvbjIsIDApLCAiQ2FsbCAlZCIsCiAJCQkJICAgIGNtZC0+YXJnMSk7 CiAJCQlicmVhazsKKwkJY2FzZSBPX1NUQVRFX0FDQ0VQVDoKKwkJCWlmIChxICE9IE5VTEwg JiYgcS0+cnVsZSA9PSBmKQorCQkJCWFjdGlvbiA9ICJBY2NlcHQiOworCQkJZWxzZQorCQkJ CWFjdGlvbiA9ICJDcmVhdGUgYWNjZXB0IHN0YXRlIjsKKwkJCWJyZWFrOworCQljYXNlIE9f U1RBVEVfREVOWToKKwkJCWlmIChxICE9IE5VTEwgJiYgcS0+cnVsZSA9PSBmKQorCQkJCWFj dGlvbiA9ICJEZW55IjsKKwkJCWVsc2UKKwkJCQlhY3Rpb24gPSAiQ3JlYXRlIGRlbnkgc3Rh dGUiOworCQkJYnJlYWs7CiAJCWRlZmF1bHQ6CiAJCQlhY3Rpb24gPSAiVU5LTk9XTiI7CiAJ CQlicmVhazsKSW5kZXg6IHN5cy9uZXRwZmlsL2lwZncvaXBfZndfcHJpdmF0ZS5oCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHN5cy9uZXRwZmlsL2lwZncvaXBfZndfcHJpdmF0ZS5oCShyZXZpc2lv biAyNzgwMjEpCisrKyBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3ByaXZhdGUuaAkod29ya2lu ZyBjb3B5KQpAQCAtMTU0LDcgKzE1NCw3IEBACiB2b2lkIGlwZndfbG9nX2JwZihpbnQpOwog dm9pZCBpcGZ3X2xvZyhzdHJ1Y3QgaXBfZndfY2hhaW4gKmNoYWluLCBzdHJ1Y3QgaXBfZncg KmYsIHVfaW50IGhsZW4sCiAgICAgc3RydWN0IGlwX2Z3X2FyZ3MgKmFyZ3MsIHN0cnVjdCBt YnVmICptLCBzdHJ1Y3QgaWZuZXQgKm9pZiwKLSAgICB1X3Nob3J0IG9mZnNldCwgdWludDMy X3QgdGFibGVhcmcsIHN0cnVjdCBpcCAqaXApOworICAgIHVfc2hvcnQgb2Zmc2V0LCB1aW50 MzJfdCB0YWJsZWFyZywgc3RydWN0IGlwICppcCwgaXBmd19keW5fcnVsZSAqcSk7CiBWTkVU X0RFQ0xBUkUodV9pbnQ2NF90LCBub3J1bGVfY291bnRlcik7CiAjZGVmaW5lCVZfbm9ydWxl X2NvdW50ZXIJVk5FVChub3J1bGVfY291bnRlcikKIFZORVRfREVDTEFSRShpbnQsIHZlcmJv c2VfbGltaXQpOwpJbmRleDogc3lzL25ldHBmaWwvaXBmdy9pcF9md19zb2Nrb3B0LmMKPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PQotLS0gc3lzL25ldHBmaWwvaXBmdy9pcF9md19zb2Nrb3B0LmMJKHJldmlz aW9uIDI3ODAyMSkKKysrIHN5cy9uZXRwZmlsL2lwZncvaXBfZndfc29ja29wdC5jCSh3b3Jr aW5nIGNvcHkpCkBAIC0xNjQ1LDYgKzE2NDUsOCBAQAogCQljYXNlIE9fU0tJUFRPOgogCQlj YXNlIE9fUkVBU1M6CiAJCWNhc2UgT19DQUxMUkVUVVJOOgorCQljYXNlIE9fU1RBVEVfQUND RVBUOgorCQljYXNlIE9fU1RBVEVfREVOWToKIGNoZWNrX3NpemU6CiAJCQlpZiAoY21kbGVu ICE9IEZfSU5TTl9TSVpFKGlwZndfaW5zbikpCiAJCQkJZ290byBiYWRfc2l6ZTsK --------------040906070105090005040205 Content-Type: application/octet-stream; name="ipfw-state-actions.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-actions.diff.sig" iQJ8BAABCgBmBQJUz81FXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3Au ZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFFQUIwM0M1OEJGREM0 NzhGAAoJEOqwPFi/3EePADAP/3EHzxUT1adKBR/DeDZ4gx5laQcFfc22KbN5v/b4ccHyrc+X /25W6ejKGSPU92wTyUX2QX3Y2u80SmkSYEd9gOV8JWgepwhK3aObuIKbr7tG0TOmRlXO533+ pUkgV0VAGPyXrsUtd3fPORYOGqc4AMCGP357efFIZdD3DPLnUgFaSN+StLH/zXC+eEOSTc9Q YauXwK0mpt9C7DCNq4oKQ+t9z7QeVFnTIzZzhGhgA4ZMsOD19mPDDOBRPIAncZkc7CvpLxQp Br6clTHOyzu4I1wLo8QDE5TAPpfMRTvbseQXbnVVPuFpZI5O6gVqqr8ldhJUdx95rnBjMees TvuR4VGDcfgRHTZU7+fVupxCQHuPnswisS4mpzRvQJUGoRobDkGFf6EWzVgT4HkLukq47EPJ Oqi+IyUjFtFn14NXoAuzJpyMMbGfoURGNXgosInYwWRFJH0Jd8LxZQM3hPMvpa77LhebPdi1 rZQsOA75Bk9I4K1VKJ/D3nPz2CduUyalVnwNAPhU1754UxB0BvJcFwAgqlyEJ3NPYCa7oCZJ IX6jWMorJ8Exfe8lPc6ZKWEWYE0MkEezCqb79+uxls8cB9Iz6Uq4Jg7H88NKGEgw5OHb8Ifo q0b6/kxu9fePqpqyWM3dLaCtyN4t4iWduAlpojyoXoMtpSKbAC4FfeIOnYpl --------------040906070105090005040205-- From owner-freebsd-ipfw@FreeBSD.ORG Mon Feb 2 19:36:55 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26798956 for ; Mon, 2 Feb 2015 19:36:55 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id DB0618AC for ; Mon, 2 Feb 2015 19:36:54 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 0ABA45C003 for ; Mon, 2 Feb 2015 22:36:13 +0300 (MSK) Message-ID: <54CFD1AC.6040503@FreeBSD.org> Date: Mon, 02 Feb 2015 22:36:12 +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.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Re: How to configure nat for interface which will be created later? References: <54CFBDF7.30301@FreeBSD.org> <54CFBFB9.9040801@FreeBSD.org> In-Reply-To: <54CFBFB9.9040801@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Feb 2015 19:36:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 02.02.2015 21:19, Lev Serebryakov wrote: >> It is possible to use non-existing interface name in via / xmit / >> recv option. It allows to write firewall which works with, say, >> VPN connection which is created AFTER firewall is loaded on >> boot. > >> But "nat X config if " doesn't allow to use non-existing >> interface name! It looks like very strict limitation, as it >> doesn't allow to include VPN to nat config! > >> Is here any solution for this problem? > Looking at "sbin/ipfw/nat.c:166" and > "sys/netpfil/ipfw/ip_fw_nat.c", it looks like this userland check > is too restrictive. > > But I'm not sure, that I'm right... To be honest, I don't understand code in sbin/ipfw/nat.c:80 (function set_addr_dynamic()) at all! First of all, it enumerates though interface list to find interface and store it index to "ifIndex" and MTU to "ifMTU" variables. After that, it continues to enumerate SAME data structure to find address. But "ifIndex" and "ifMTU" are never used again! - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJUz9GsXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePdF0QALinIRoUkZ1uUAiAUAbLHaGe JB6rKraVUt3ps37mUgiWFD6YaiVDA+lTgPpm85aRtc21b+I7CAPCu6urZqhlZtRc DMO/JCPLa6EPx2o2TA6UhCJ5AKHtmRb50V6KhhDXrR1NaZCQ+a5PZZY9D/MhHYa2 O/F8fFXr+9MHeocQ2ZjYvImjIVTM/nSGRLleq0M539I6Vsa/Eblw2fe/8ugSmTjB eKFuzxXM37QAcpj6exhuRIOxQy8Rp9WVCsm+j6RaMd3L5AjUNd+EP4Cjz3z9YlEx R2uJWlXwfxKo4wkCBC65R+IuHiRoQOr6COERKijmReAEBZ9w9CkpTbZ1Jv9Ri/bq WcanR8o+GO30QKXO1gLckTdikeDKLxsIfuf1CAgJivf9HSV8UzKy6ktdEF7rWP3d WoBmzpsoGpdzNhgCW2Px1J4ZXzM2mfzxxJCulFYfrapCC3G+fQ42ZmU5QXE9w6LZ xdMB5MivxSjxrnrFRAheG0BCaIJhR9FwT1HKulO/cxBZ21lcoe+aBwhOOr3GRC3u 70g2VX5Ey6V7PFWNsglaFKStQdAgavUqfGLBaMmnvqTT3jljPzdkQQrP7eBdwuVL sW8JgA2ksh/lHHIm0NYc1yMIYxrW+yB7tsVLtygTn+K0aQMXPTMB70Z05TWlCb2H tgGvKYbyYcm8X213znx/ =q9nY -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 3 06:44:56 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A21B227B; Tue, 3 Feb 2015 06:44:56 +0000 (UTC) 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 771BDA33; Tue, 3 Feb 2015 06:44:56 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t136ioF6037065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 2 Feb 2015 22:44:52 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D06E5C.3090701@freebsd.org> Date: Tue, 03 Feb 2015 14:44:44 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> In-Reply-To: <54CFCD45.9070304@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 06:44:56 -0000 On 2/3/15 3:17 AM, Lev Serebryakov wrote: > > I propose two new actions: state-allow and state-deny. > > They imply "keep-state" and create new dynamic rules, when called > directly, but pass packet to NEXT rule after that (don't stop search). > > When they are called as dynamic rule, they acts as "allow" and "deny". > > So, stateful firewall with NAT could be rewritten like this: > > add 1000 skipto 2000 all from any to any out xmit outIface > add 1010 skipto 3000 all from any to any in recv outIface > > add 2000 state-allow from any to any // keep-state is implied > add 2010 nat NR from any to any // No "out" here! > add 2020 allow all from any to any > > add 3000 nat NR from any to any > add 3010 check-state // Use dynamic rule based on 2000 as "allow" here > > What do you think? I understand what you are trying to do.. but part of the usefulness of the state runes is that they can be any action, not just allow and deny. I might try the following action: record: (or record-only) it allows the rule to be stored, but the action is not performed. on check-state, the rule is performed.. so skipto 2000 ip from me to fred 80 record-only out xmit bge0 would do nothing but record the session and on input the session packet would skipto 2000 you could do deny or accept as well so it's a superset of what you suggest. I'm not sure where in the rule record-only shoudl be put.. maybe ipfw add 1000 log record-only skipto 2000 tcp from me to fred 80,443 out xmit bge0 might be more syntactically correct? What I would find more useful, is separate state rules for each interface. so you could not have the danger of a packet on interface A adding a rule that eventually does something unexpected on a packet on interface B. looking at my own rules I don't seem to have a problem.. -------- Just for kicks, here is the base ipfw script.. just sets up the framework --- #!/bin/sh fwcmd="/sbin/ipfw" # Suck in the configuration variables. if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi # set these to your outside interface network and netmask and ip oif="tun0" onet="192.168.36.0" omask="24" oip="x.x.x.x" # set these to your inside interface network and netmask and ip iif="vr0" inet="192.168.2.0" imask="255.255.255.0" iip="192.168.2.21" # for not the natd target is us but change this if you # change that in natd.conf natd_target=${oip} work_vpnserver=y.y.y.y INCOMING=4000 OUTGOING=8000 LOCAL=1000 SET=1 sysctl net.inet.ip.fw.enable=0 ${fwcmd} -q flush ${fwcmd} -q table 1 flush ${fwcmd} -q table 2 flush ${fwcmd} -q table 3 flush ${fwcmd} -q table 4 flush ${fwcmd} table 1 add 10.0.0.0/8 ${fwcmd} table 1 add 172.16.0.0/12 #${fwcmd} table 1 add 192.168.0.0/16 # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes # RESERVED-1, DHCP auto-configuration, NET-TEST, MULTICAST (class D), # and class E) on the outside interface ${fwcmd} table 1 add 0.0.0.0/8 ${fwcmd} table 1 add 169.254.0.0/16 ${fwcmd} table 1 add 192.0.2.0/24 ${fwcmd} table 1 add 224.0.0.0/4 ${fwcmd} table 1 add 240.0.0.0/4 # add legit sources of ssh.. DNS is not up yet so use IPs # could add to /etc/hosts I guess. # myotherhouse.org ${fwcmd} table 2 add a.b.c.d # work ${fwcmd} table 2 add c.d.e.f/24 # my vps ${fwcmd} table 2 add f.g.h.i/24 # add legit DNS tcp (zone) sources # my.dns.friends ${fwcmd} table 3 add m.n.o.p # my.dns.friend ${fwcmd} table 3 add q.r.s.t # my.vps ${fwcmd} table 3 add f.g.h.i # Add our local networks here ${fwcmd} table 4 add 192.168.2.0/24 ${fwcmd} table 4 add 172.16.15.0/24 # common spoofing code # --------------- ALL PACKETS START HERE. ------------ ${fwcmd} set disable ${SET} # Stop localhost spoofing ${fwcmd} add 100 pass all from any to any via lo0 ${fwcmd} add 200 deny log all from any to 127.0.0.0/8 ${fwcmd} add 300 deny log ip from 127.0.0.0/8 to any # If we've already decided on it. keep our word. ${fwcmd} add check-state #-------- Interception rules for external interfaces go here ------- #-------- Internal traffic. generally don't care # except to stop spoofing. # make extra sure we don't block DHCP to our server (me) # as initial request will be from 0.0.0.0/0 ${fwcmd} add ${LOCAL} set ${SET} allow udp from any to any 67 in recv ${iif} ${fwcmd} add allow udp from any 67 to any out xmit ${iif} # other wise it has to be to and from a net we actually have. ${fwcmd} add deny log all from not "table(4)" to any in recv ${iif} ${fwcmd} add deny log all from any to not "table(4)" out xmit ${iif} ${fwcmd} add reject log tcp from "table(5)" to any 80,443 in recv vr0 ${fwcmd} add allow ip from any to any sysctl net.inet.ip.fw.enable=1 -------- and now the rules for my external interface.. you run this after the other file. note that the rules go into a separate set and can be disabled at once. #!/bin/sh set -x fwcmd="/sbin/ipfw" # Suck in the configuration variables. if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi # set these to your outside interface network and netmask and ip oif="vr2" oip="$1" onet="$2" omask="$3" # set these to your inside interface network and netmask and ip iif="vr0" inet="192.168.2.0" imask="255.255.255.0" iip="192.168.2.21" # for not the natd target is us but change this if you # change that in natd.conf natd_target=${oip} work_vpnserver=64.244.102.15 INTERCEPT=610 INCOMING=14000 OUTGOING=18000 NATD2=8669 SET=2 sysctl net.inet.ip.fw.enable=0 ${fwcmd} -q delete ${INTERCEPT} ${fwcmd} set disable ${SET} # effectively clear it ${fwcmd} set move 30 to ${SET} # common spoofing code # --------------- ALL PACKETS START HERE. ------------ ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${INCOMING} ip from any to any in recv ${oif} ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${OUTGOING} ip from any to any out xmit ${oif} #-------- Internal traffic. generally don't care Add in a new incoming and outgoing section for the new interface #------- INCOMING # don't allow packets from the wrong net! ${fwcmd} add ${INCOMING} set ${SET} deny log all from "table(4)" to any # in fact don't accept packets that are not for this interface exactly ${fwcmd} add set ${SET} deny log ip from any to not ${oip} # Allow access to our ssh from trusted places (work, freebsd (sometimes)) ${fwcmd} add set ${SET} pass tcp from "table(2)" to ${oip} 22 setup keep-state # allow our DNS secondaries to get zone transfers ${fwcmd} add set ${SET} pass tcp from "table(3)" to ${oip} 53 setup keep-state # allow DNS requests, since we are authoratitive ${fwcmd} add set ${SET} pass udp from any to ${oip} 53 # Allow setup of incoming email # not on this interface # me, DNS and root can start outgoing sessions and have # them come in if there is a waiting socket # !!@# Don't do this it breaks ntp from inside # ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 0 # ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 53 # ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 1000 # ignore any mention of RFC1918 nets on the outside interface ${fwcmd} add set ${SET} deny log all from any to "table(1)" # except the ${fwcmd} add set ${SET} deny log not icmp from "table(1)" to any #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v INCOMING NAT POINT ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v # NAT anything that is left and trust NATD ${fwcmd} add set ${SET} divert ${NATD2} all from any to any #After translation.. trust Nat to filter non matches # explicitly allow NAT-T from the vpn server to inside nets ${fwcmd} add set ${SET} allow udp from ${work_vpnserver} to "table(4)" # Allow TCP through if setup succeeded . # bypass the logging step. too much data ${fwcmd} add set ${SET} allow tcp from any to any established # take note of unexpected stuff. then drop it. # hmm, NAtd must have let this through why? ${fwcmd} add set ${SET} drop log ip from any to ${natd_target} # Allow IP fragments to pass through (NOPE) # ${fwcmd} add set ${SET} pass all from any to any frag # XXX remove this if you turn on the target option on # natd to allow a server # Reject & Log all setup of incoming connections from the outside # that have not been explicitly allowed above. ${fwcmd} add set ${SET} deny log tcp from any to ${natd_target} setup # anything here should be logged. it's intersting. ${fwcmd} add set ${SET} count log ip from any to any # after that gauntlet, allow it to proceed. ${fwcmd} add set ${SET} allow ip from any to any #----- OUTGOING # Stop RFC1918 nets getting out to the outside interface # except for the wierdness of our next hop being such an address. ${fwcmd} add ${OUTGOING} set ${SET} allow icmp from ${oip} to ${onet}:${omask} keep-state ${fwcmd} add set ${SET} deny log all from any to "table(1)" # The firewall and inside can talk out if it wants to. # these are local sessions by definition. ${fwcmd} add set ${SET} pass all from ${oip} to any keep-state #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v OUTGOING NAT POINT ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v ${fwcmd} add set ${SET} divert ${NATD2} all from any to any out recv ${iif} # just in case natd goes wierd. ${fwcmd} add set ${SET} deny log all from "table(1)" to any # in fact don't allow packets out that are not from this interface exactly ${fwcmd} add set ${SET} deny log ip from not ${oip} to any ${fwcmd} add set ${SET} allow all from any to any ${fwcmd} set enable ${SET} sysctl net.inet.ip.fw.enable=1 and here's rules for un untrusted tunnel this file can also be run after the main one when hte tunnel is in use. I'm not using this one at the moment, so I'm not sure it works but you can get the idea.. I add a separate script file for each interface.. and they slot in separate rules as needed. #!/bin/sh fwcmd="/sbin/ipfw" # Suck in the configuration variables. if [ -z "${source_rc_confs_defined}" ]; then if [ -r /etc/defaults/rc.conf ]; then . /etc/defaults/rc.conf source_rc_confs elif [ -r /etc/rc.conf ]; then . /etc/rc.conf fi fi # set these to your inside interface network and netmask and ip iif="vr0" inet="192.168.2.0" imask="255.255.255.0" iip="192.168.2.21" # set these to your outside interface network and netmask and ip oif="tun0" onet="192.168.36.0" omask="24" oip="l.m.n.o" INTERCEPT=500 INCOMING=4000 OUTGOING=8000 SET=1 # for now the natd target is us but change this if you # change that in natd.conf natd_target=${oip} work_vpnserver=t.u.v.w sysctl net.inet.ip.fw.enable=0 #-------- Select direction and interface class ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${INCOMING} ip from any to any in recv ${oif} ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${OUTGOING} ip from any to any out xmit ${oif} #------- INCOMING # don't allow packets from the wrong net! ${fwcmd} add ${INCOMING} set ${SET} deny log all from "table(4)" to any # in fact don't accept packets that are not for this interface exactly ${fwcmd} add set ${SET} deny log ip from any to not ${oip} # Allow access to our ssh from trusted places (work, freebsd, (sometimes)) ${fwcmd} add set ${SET} pass tcp from "table(2)" to ${oip} 22 setup keep-state # allow our DNS secondaries to get zone transfers ${fwcmd} add set ${SET} pass tcp from "table(3)" to ${oip} 53 setup keep-state # allow DNS requests, since we are authoratitive ${fwcmd} add set ${SET} pass udp from any to ${oip} 53 # Allow setup of incoming email # julian and root can start outgoing sessions and have them come in if there is a waiting socket :-) ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 0 ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 53 ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 1000 # ignore any mention of RFC1918 nets on the outside interface ${fwcmd} add set ${SET} deny log all from any to "table(1)" ${fwcmd} add set ${SET} deny log not icmp from "table(1)" to any #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v INCOMING NAT POINT ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v # NAT anything that is left and trust NATD ${fwcmd} add set ${SET} divert natd all from any to any #After translation # explicitly allow NAT-T from the vpn server to inside nets ${fwcmd} add set ${SET} allow udp from ${work_vpnserver} to "table(4)" # Allow TCP through if setup succeeded . # bypass the logging step. too much data ${fwcmd} add set ${SET} allow tcp from any to any established # take note of unexpected stuff. then drop it. ${fwcmd} add set ${SET} drop log ip from any to ${natd_target} # Allow IP fragments to pass through (NOPE) # ${fwcmd} add set ${SET} pass all from any to any frag # XXX remove this if you turn on the target option on # natd to allow a server # Reject & Log all setup of incoming connections from the outside # that have not been explicitly allowed above. ${fwcmd} add set ${SET} deny log tcp from any to ${natd_target} setup # anything here should be logged. it's interesting. ${fwcmd} add set ${SET} count log ip from any to any #currently slam that door .. this rule comes and goes depending on if I need it. ${fwcmd} add set ${SET} deny log ip from any to any # after that gauntlet, allow it to proceed. ${fwcmd} add set ${SET} allow ip from any to any #----- OUTGOING # Stop RFC1918 nets getting out to the outside interface # except for the wierdness of our next hop being such an address. ${fwcmd} add ${OUTGOING} set ${SET} allow icmp from ${oip} to ${onet}/${omask} keep-state ${fwcmd} add set ${SET} deny log all from any to "table(1)" # The firewall (and my laptop) can talk out if it wants to. # these are local sessions by definition. ${fwcmd} add set ${SET} pass all from ${oip} to any keep-state # ${fwcmd} add set ${SET} pass udp from ${oip} to any keep-state # ${fwcmd} add set ${SET} pass icmp from ${oip} to any keep-state # Allow NTP queries out in the world from the firewall. # ${fwcmd} add set ${SET} pass udp from ${oip} to any 123 keep-state # Allow DNS queries out in the world from the firewall. # ${fwcmd} add set ${SET} pass udp from ${oip} to any 53 keep-state #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v OUTGOING NAT POINT ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v ${fwcmd} add set ${SET} divert natd all from any to any out recv ${iif} # just in case natd goes wierd. ${fwcmd} add set ${SET} deny log all from "table(1)" to any # in fact don't allow packets out that are not from this interface exactly ${fwcmd} add set ${SET} deny log ip from not ${oip} to any ${fwcmd} add set ${SET} allow all from any to any ${fwcmd} set enable ${SET} sysctl net.inet.ip.fw.enable=1 From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 3 06:54:19 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ADF2F445; Tue, 3 Feb 2015 06:54:19 +0000 (UTC) Received: from mail-pa0-x22d.google.com (mail-pa0-x22d.google.com [IPv6:2607:f8b0:400e:c03::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 82679B11; Tue, 3 Feb 2015 06:54:19 +0000 (UTC) Received: by mail-pa0-f45.google.com with SMTP id et14so92534913pad.4; Mon, 02 Feb 2015 22:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2X6dA5vpZissLKDr2jLs7L6YuT1CFvavMDFPfqnq9/0=; b=OBva4X9y3Nzt08mhdJTYRXqKEo1P2MT7oh+QSkDEwDXTzWlYv3c8gu2pgYSRBFKFZ0 q+sIPnF8vXM8ijPer6YjjetCxGRtsVS8G6xWRQJBJLQpHve2ikFUnwN5Ej8iqg804AAy hZSlGXuxmqdX1rLa75wnYRc9ETBnwZAynrizqpvCEfBK3R1AvLcd9mSLTErP271ETr0Z wz/px/BHyTWVxbL6wMeCcHyGXMqzhgAPt1XmSXuvUjrh8pe5DrptiZtPzkNUV1xoOM4x VQVWXjc3NId5Re8g8a1ofwF3WUCSuLmUi/p3UO1vMI/zi3j6WNaL2Y/317p/YQ0jErK6 xf9w== MIME-Version: 1.0 X-Received: by 10.70.94.129 with SMTP id dc1mr11353357pdb.70.1422946458929; Mon, 02 Feb 2015 22:54:18 -0800 (PST) Received: by 10.70.45.228 with HTTP; Mon, 2 Feb 2015 22:54:18 -0800 (PST) In-Reply-To: <54D06E5C.3090701@freebsd.org> References: <54CFCD45.9070304@FreeBSD.org> <54D06E5C.3090701@freebsd.org> Date: Tue, 3 Feb 2015 14:54:18 +0800 Message-ID: Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny From: bycn82 To: Julian Elischer Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ipfw , lev@freebsd.org, freebsd-net X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 06:54:19 -0000 *cool, I like this, it got some points.* *though the email is too looooong to be read.* On 3 February 2015 at 14:44, Julian Elischer wrote: > On 2/3/15 3:17 AM, Lev Serebryakov wrote: > >> >> I propose two new actions: state-allow and state-deny. >> >> They imply "keep-state" and create new dynamic rules, when called >> directly, but pass packet to NEXT rule after that (don't stop search). >> >> When they are called as dynamic rule, they acts as "allow" and "deny". >> >> So, stateful firewall with NAT could be rewritten like this: >> >> add 1000 skipto 2000 all from any to any out xmit outIface >> add 1010 skipto 3000 all from any to any in recv outIface >> >> add 2000 state-allow from any to any // keep-state is implied >> add 2010 nat NR from any to any // No "out" here! >> add 2020 allow all from any to any >> >> add 3000 nat NR from any to any >> add 3010 check-state // Use dynamic rule based on 2000 as "allow" here >> >> What do you think? >> > > I understand what you are trying to do.. > but part of the usefulness of the state runes is that they > can be any action, not just allow and deny. > I might try the following action: > > record: (or record-only) > it allows the rule to be stored, but the action is not performed. > on check-state, the rule is performed.. > > so skipto 2000 ip from me to fred 80 record-only out xmit bge0 > would do nothing but record the session > and on input the session packet would skipto 2000 > > you could do deny or accept as well so it's a superset of what you > suggest. > I'm not sure where in the rule record-only shoudl be put.. > maybe > > ipfw add 1000 log record-only skipto 2000 tcp from me to fred 80,443 out > xmit bge0 > > might be more syntactically correct? > > What I would find more useful, is separate state rules for each interface. > so you could not have the danger of a packet on interface A adding a rule > that eventually does something unexpected on a packet on interface B. > > > looking at my own rules I don't seem to have a problem.. > -------- > Just for kicks, > here is the base ipfw script.. just sets up the framework > > --- > #!/bin/sh > > fwcmd="/sbin/ipfw" > > # Suck in the configuration variables. > if [ -z "${source_rc_confs_defined}" ]; then > if [ -r /etc/defaults/rc.conf ]; then > . /etc/defaults/rc.conf > source_rc_confs > elif [ -r /etc/rc.conf ]; then > . /etc/rc.conf > fi > fi > > > # set these to your outside interface network and netmask and ip > oif="tun0" > onet="192.168.36.0" > omask="24" > oip="x.x.x.x" > > > # set these to your inside interface network and netmask and ip > iif="vr0" > inet="192.168.2.0" > imask="255.255.255.0" > iip="192.168.2.21" > > # for not the natd target is us but change this if you > # change that in natd.conf > natd_target=${oip} > work_vpnserver=y.y.y.y > > INCOMING=4000 > OUTGOING=8000 > LOCAL=1000 > SET=1 > > sysctl net.inet.ip.fw.enable=0 > ${fwcmd} -q flush > ${fwcmd} -q table 1 flush > ${fwcmd} -q table 2 flush > ${fwcmd} -q table 3 flush > ${fwcmd} -q table 4 flush > > ${fwcmd} table 1 add 10.0.0.0/8 > ${fwcmd} table 1 add 172.16.0.0/12 > #${fwcmd} table 1 add 192.168.0.0/16 > # Stop draft-manning-dsua-03.txt (1 May 2000) nets (includes > # RESERVED-1, DHCP auto-configuration, NET-TEST, MULTICAST (class > D), > # and class E) on the outside interface > ${fwcmd} table 1 add 0.0.0.0/8 > ${fwcmd} table 1 add 169.254.0.0/16 > ${fwcmd} table 1 add 192.0.2.0/24 > ${fwcmd} table 1 add 224.0.0.0/4 > ${fwcmd} table 1 add 240.0.0.0/4 > > # add legit sources of ssh.. DNS is not up yet so use IPs > # could add to /etc/hosts I guess. > # myotherhouse.org > ${fwcmd} table 2 add a.b.c.d > # work > ${fwcmd} table 2 add c.d.e.f/24 > # my vps > ${fwcmd} table 2 add f.g.h.i/24 > > # add legit DNS tcp (zone) sources > # my.dns.friends > ${fwcmd} table 3 add m.n.o.p > # my.dns.friend > ${fwcmd} table 3 add q.r.s.t > # my.vps > ${fwcmd} table 3 add f.g.h.i > > # Add our local networks here > ${fwcmd} table 4 add 192.168.2.0/24 > ${fwcmd} table 4 add 172.16.15.0/24 > > # common spoofing code > # --------------- ALL PACKETS START HERE. ------------ > > ${fwcmd} set disable ${SET} > > # Stop localhost spoofing > ${fwcmd} add 100 pass all from any to any via lo0 > ${fwcmd} add 200 deny log all from any to 127.0.0.0/8 > ${fwcmd} add 300 deny log ip from 127.0.0.0/8 to any > > # If we've already decided on it. keep our word. > ${fwcmd} add check-state > > #-------- Interception rules for external interfaces go here ------- > > #-------- Internal traffic. generally don't care > # except to stop spoofing. > # make extra sure we don't block DHCP to our server (me) > # as initial request will be from 0.0.0.0/0 > > ${fwcmd} add ${LOCAL} set ${SET} allow udp from any to any 67 in > recv ${iif} > ${fwcmd} add allow udp from any 67 to any out xmit ${iif} > > # other wise it has to be to and from a net we actually have. > ${fwcmd} add deny log all from not "table(4)" to any in recv ${iif} > ${fwcmd} add deny log all from any to not "table(4)" out xmit > ${iif} > > ${fwcmd} add reject log tcp from "table(5)" to any 80,443 in recv > vr0 > > ${fwcmd} add allow ip from any to any > > > > sysctl net.inet.ip.fw.enable=1 > > -------- > and now the rules for my external interface.. > you run this after the other file. note that the rules go into a separate > set > and can be disabled at once. > > #!/bin/sh > set -x > fwcmd="/sbin/ipfw" > > # Suck in the configuration variables. > if [ -z "${source_rc_confs_defined}" ]; then > if [ -r /etc/defaults/rc.conf ]; then > . /etc/defaults/rc.conf > source_rc_confs > elif [ -r /etc/rc.conf ]; then > . /etc/rc.conf > fi > fi > > # set these to your outside interface network and netmask and ip > oif="vr2" > oip="$1" > onet="$2" > omask="$3" > > > # set these to your inside interface network and netmask and ip > iif="vr0" > inet="192.168.2.0" > imask="255.255.255.0" > iip="192.168.2.21" > > # for not the natd target is us but change this if you > # change that in natd.conf > natd_target=${oip} > work_vpnserver=64.244.102.15 > > INTERCEPT=610 > INCOMING=14000 > OUTGOING=18000 > NATD2=8669 > SET=2 > > sysctl net.inet.ip.fw.enable=0 > ${fwcmd} -q delete ${INTERCEPT} > ${fwcmd} set disable ${SET} > # effectively clear it > ${fwcmd} set move 30 to ${SET} > > > # common spoofing code > # --------------- ALL PACKETS START HERE. ------------ > > > ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${INCOMING} ip from > any to any in recv ${oif} > ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${OUTGOING} ip from > any to any out xmit ${oif} > > #-------- Internal traffic. generally don't care > Add in a new incoming and outgoing section for the new interface > > #------- INCOMING > # don't allow packets from the wrong net! > ${fwcmd} add ${INCOMING} set ${SET} deny log all from "table(4)" > to any > > # in fact don't accept packets that are not for this interface > exactly > ${fwcmd} add set ${SET} deny log ip from any to not ${oip} > > # Allow access to our ssh from trusted places (work, freebsd > (sometimes)) > ${fwcmd} add set ${SET} pass tcp from "table(2)" to ${oip} 22 > setup keep-state > > # allow our DNS secondaries to get zone transfers > ${fwcmd} add set ${SET} pass tcp from "table(3)" to ${oip} 53 > setup keep-state > > # allow DNS requests, since we are authoratitive > ${fwcmd} add set ${SET} pass udp from any to ${oip} 53 > > # Allow setup of incoming email # not on this interface > > # me, DNS and root can start outgoing sessions and have > # them come in if there is a waiting socket > # !!@# Don't do this it breaks ntp from inside > # ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 0 > # ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 53 > # ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 1000 > > # ignore any mention of RFC1918 nets on the outside interface > ${fwcmd} add set ${SET} deny log all from any to "table(1)" > # except the > ${fwcmd} add set ${SET} deny log not icmp from "table(1)" to any > > #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v INCOMING NAT POINT > ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v > # NAT anything that is left and trust NATD > ${fwcmd} add set ${SET} divert ${NATD2} all from any to any > > #After translation.. trust Nat to filter non matches > > # explicitly allow NAT-T from the vpn server to inside nets > ${fwcmd} add set ${SET} allow udp from ${work_vpnserver} to > "table(4)" > > # Allow TCP through if setup succeeded . > # bypass the logging step. too much data > ${fwcmd} add set ${SET} allow tcp from any to any established > > # take note of unexpected stuff. then drop it. > # hmm, NAtd must have let this through why? > ${fwcmd} add set ${SET} drop log ip from any to ${natd_target} > > # Allow IP fragments to pass through (NOPE) > # ${fwcmd} add set ${SET} pass all from any to any frag > > # XXX remove this if you turn on the target option on > # natd to allow a server > # Reject & Log all setup of incoming connections from the outside > # that have not been explicitly allowed above. > ${fwcmd} add set ${SET} deny log tcp from any to ${natd_target} > setup > > # anything here should be logged. it's intersting. > ${fwcmd} add set ${SET} count log ip from any to any > > # after that gauntlet, allow it to proceed. > ${fwcmd} add set ${SET} allow ip from any to any > > > > #----- OUTGOING > # Stop RFC1918 nets getting out to the outside interface > # except for the wierdness of our next hop being such an address. > ${fwcmd} add ${OUTGOING} set ${SET} allow icmp from ${oip} to > ${onet}:${omask} keep-state > ${fwcmd} add set ${SET} deny log all from any to "table(1)" > > # The firewall and inside can talk out if it wants to. > # these are local sessions by definition. > ${fwcmd} add set ${SET} pass all from ${oip} to any keep-state > > #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v OUTGOING NAT POINT > ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v > ${fwcmd} add set ${SET} divert ${NATD2} all from any to any out > recv ${iif} > > # just in case natd goes wierd. > ${fwcmd} add set ${SET} deny log all from "table(1)" to any > # in fact don't allow packets out that are not from this > interface exactly > ${fwcmd} add set ${SET} deny log ip from not ${oip} to any > ${fwcmd} add set ${SET} allow all from any to any > > ${fwcmd} set enable ${SET} > sysctl net.inet.ip.fw.enable=1 > > and here's rules for un untrusted tunnel > this file can also be run after the main one when hte tunnel is in use. > I'm not using this one at the moment, so I'm not sure it works but you can > get the idea.. > I add a separate script file for each interface.. and they slot in > separate rules as needed. > > #!/bin/sh > fwcmd="/sbin/ipfw" > > # Suck in the configuration variables. > if [ -z "${source_rc_confs_defined}" ]; then > if [ -r /etc/defaults/rc.conf ]; then > . /etc/defaults/rc.conf > source_rc_confs > elif [ -r /etc/rc.conf ]; then > . /etc/rc.conf > fi > fi > > > > # set these to your inside interface network and netmask and ip > iif="vr0" > inet="192.168.2.0" > imask="255.255.255.0" > iip="192.168.2.21" > > # set these to your outside interface network and netmask and ip > oif="tun0" > onet="192.168.36.0" > omask="24" > oip="l.m.n.o" > INTERCEPT=500 > INCOMING=4000 > OUTGOING=8000 > SET=1 > > # for now the natd target is us but change this if you > # change that in natd.conf > natd_target=${oip} > work_vpnserver=t.u.v.w > > sysctl net.inet.ip.fw.enable=0 > > #-------- Select direction and interface class > ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${INCOMING} ip from > any to any in recv ${oif} > ${fwcmd} add ${INTERCEPT} set ${SET} skipto ${OUTGOING} ip from > any to any out xmit ${oif} > > > #------- INCOMING > # don't allow packets from the wrong net! > ${fwcmd} add ${INCOMING} set ${SET} deny log all from "table(4)" > to any > > # in fact don't accept packets that are not for this interface > exactly > ${fwcmd} add set ${SET} deny log ip from any to not ${oip} > > # Allow access to our ssh from trusted places (work, freebsd, > (sometimes)) > ${fwcmd} add set ${SET} pass tcp from "table(2)" to ${oip} 22 > setup keep-state > > # allow our DNS secondaries to get zone transfers > ${fwcmd} add set ${SET} pass tcp from "table(3)" to ${oip} 53 > setup keep-state > > # allow DNS requests, since we are authoratitive > ${fwcmd} add set ${SET} pass udp from any to ${oip} 53 > > # Allow setup of incoming email > > # julian and root can start outgoing sessions and have them come > in if there is a waiting socket :-) > ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 0 > ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 53 > ${fwcmd} add set ${SET} allow ip from any to ${oip} uid 1000 > > # ignore any mention of RFC1918 nets on the outside interface > ${fwcmd} add set ${SET} deny log all from any to "table(1)" > ${fwcmd} add set ${SET} deny log not icmp from "table(1)" to any > > #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v INCOMING NAT POINT > ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v > # NAT anything that is left and trust NATD > ${fwcmd} add set ${SET} divert natd all from any to any > > #After translation > > # explicitly allow NAT-T from the vpn server to inside nets > ${fwcmd} add set ${SET} allow udp from ${work_vpnserver} to > "table(4)" > > # Allow TCP through if setup succeeded . > # bypass the logging step. too much data > ${fwcmd} add set ${SET} allow tcp from any to any established > > # take note of unexpected stuff. then drop it. > ${fwcmd} add set ${SET} drop log ip from any to ${natd_target} > > # Allow IP fragments to pass through (NOPE) > # ${fwcmd} add set ${SET} pass all from any to any frag > > # XXX remove this if you turn on the target option on > # natd to allow a server > # Reject & Log all setup of incoming connections from the outside > # that have not been explicitly allowed above. > ${fwcmd} add set ${SET} deny log tcp from any to ${natd_target} > setup > > # anything here should be logged. it's interesting. > ${fwcmd} add set ${SET} count log ip from any to any > > #currently slam that door .. this rule comes and goes depending on > if I need it. > ${fwcmd} add set ${SET} deny log ip from any to any > > # after that gauntlet, allow it to proceed. > ${fwcmd} add set ${SET} allow ip from any to any > > > > #----- OUTGOING > # Stop RFC1918 nets getting out to the outside interface > # except for the wierdness of our next hop being such an address. > ${fwcmd} add ${OUTGOING} set ${SET} allow icmp from ${oip} to > ${onet}/${omask} keep-state > ${fwcmd} add set ${SET} deny log all from any to "table(1)" > > # The firewall (and my laptop) can talk out if it wants to. > # these are local sessions by definition. > ${fwcmd} add set ${SET} pass all from ${oip} to any keep-state > # ${fwcmd} add set ${SET} pass udp from ${oip} to any keep-state > # ${fwcmd} add set ${SET} pass icmp from ${oip} to any keep-state > > # Allow NTP queries out in the world from the firewall. > # ${fwcmd} add set ${SET} pass udp from ${oip} to any 123 keep-state > > # Allow DNS queries out in the world from the firewall. > # ${fwcmd} add set ${SET} pass udp from ${oip} to any 53 keep-state > > #^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v OUTGOING NAT POINT > ^v^v^v^v^v^v^v^v^v^v^v^v^v^v^v > ${fwcmd} add set ${SET} divert natd all from any to any out recv > ${iif} > > # just in case natd goes wierd. > ${fwcmd} add set ${SET} deny log all from "table(1)" to any > # in fact don't allow packets out that are not from this > interface exactly > ${fwcmd} add set ${SET} deny log ip from not ${oip} to any > ${fwcmd} add set ${SET} allow all from any to any > > ${fwcmd} set enable ${SET} > > sysctl net.inet.ip.fw.enable=1 > > > > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw > To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" > From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 3 09:30:20 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 784BF4F8; Tue, 3 Feb 2015 09:30:20 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 014F1CE8; Tue, 3 Feb 2015 09:30:20 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id DB66C5C003; Tue, 3 Feb 2015 12:30:06 +0300 (MSK) Message-ID: <54D0951F.2000304@FreeBSD.org> Date: Tue, 03 Feb 2015 12:30:07 +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.4.0 MIME-Version: 1.0 To: Julian Elischer , freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <54D06E5C.3090701@freebsd.org> In-Reply-To: <54D06E5C.3090701@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 09:30:20 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03.02.2015 09:44, Julian Elischer wrote: >> So, stateful firewall with NAT could be rewritten like this: >> >> add 1000 skipto 2000 all from any to any out xmit outIface add >> 1010 skipto 3000 all from any to any in recv outIface >> >> add 2000 state-allow from any to any // keep-state is implied add >> 2010 nat NR from any to any // No "out" here! add 2020 allow all >> from any to any >> >> add 3000 nat NR from any to any add 3010 check-state // Use >> dynamic rule based on 2000 as "allow" here >> >> What do you think? > > I understand what you are trying to do.. but part of the usefulness > of the state runes is that they can be any action, not just allow > and deny. Typically, it is Ok that they are "terminal" actions. And typicaly you don't need anything non-terminal-now but "allow" in NAT case :) > record: (or record-only) it allows the rule to be stored, but the > action is not performed. on check-state, the rule is performed.. I think, it hould be option like "record-only" instead of "keep-state". Problem is, it adds "if" branch for EACH action (in kernel code). IMHO, it is very prohibitive. I've though about that, but decide it is too expensive to have "if (!iHaveRecordOnly || fromDynamic)" for EACH action, always. It could be done easily, of course. > so skipto 2000 ip from me to fred 80 record-only out xmit bge0 > would do nothing but record the session and on input the session > packet would skipto 2000 Nooooo, not "skipto" again :) > What I would find more useful, is separate state rules for each > interface. so you could not have the danger of a packet on > interface A adding a rule that eventually does something unexpected > on a packet on interface B. Still, in case of NAT and, especially, in case of multiple NATs with "nat global" added, it doesn't solve problem of ugliness of hacks we need use to add statefullness. > looking at my own rules I don't seem to have a problem.. You have "check-state" only once, on entrance, before all NATs, so it could work only for packets which don't need NAT. And looks like (correct me if I'm wrong) you don't try to track states of connections passed through NAT. - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0JUfXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePFCUP/jqRAvX00JUQyEV0hmffmh4w iTHeK8v56k76VTm2s/Gm2Mjt5EjqXdjKal5eZ6KfQrkPUBHSkmaA+Grig7AoSw81 2XUX2vj/ihkB8fpC7U5enG8UDDn/KV6rEq8nkHfZ0wEzIyGPXPCsC/8kGTotBnZo oI0JX9uehDmOgqdOL22jeSX3vgrMZu/V7G9ckrEadmSp7yyiPdwEkTqzZsyt8Df4 n6RT7ox0vezpdZDE0Xsx1zNU9iEd1ViT+gEPgSfHYiEyhml1bnv3qF5pPMZEtYEO /DG6RFfhel6gukrGZ2Yu7tUaGj+QEXXGz5syuxDmIUBzqdHLi9upoX0TbfDH2L3L KkcVyYdrcyEQwkeZO3gvugGLnNTRJMDOvrfPR8sgcfmWj2kaVYZZiA/SPr/76XqX ypCAHnaTbytnkOk0k6afjfofSQ8Gc5mPbll9N+uVkS3Ne11kf1uZKIUgsy/5rtw0 59D3Z5OyFJwYscMMjFkt/rAdLlaD2gd5Et/Jk751UO/x49VXdOz/6ErHZWvtg3io ku1E8W5SRow+EurWVBmIKkbcuCkUW2eaM30o6LYWwkYB8DdG79ihXfYep6Lj3074 1mvuPsWeouBdxbv9ZWu270aD3MmyNE5IL7aaf86XCa2gG4V+dZisw97v4ZRAHenZ YdcZpExF2wAV3VVAgO74 =tnKG -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 3 10:04:23 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AAC4EDC3; Tue, 3 Feb 2015 10:04:23 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 07C2DFA; Tue, 3 Feb 2015 10:04:22 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t13A4Fcb073244; Tue, 3 Feb 2015 21:04:16 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 3 Feb 2015 21:04:15 +1100 (EST) From: Ian Smith To: Lev Serebryakov Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny In-Reply-To: <54CFCD45.9070304@FreeBSD.org> Message-ID: <20150203205715.A38620@sola.nimnet.asn.au> References: <54CFCD45.9070304@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20150203205715.E38620@sola.nimnet.asn.au> Cc: freebsd-ipfw , freebsd-net X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 10:04:23 -0000 On Mon, 2 Feb 2015 22:17:25 +0300, Lev Serebryakov wrote: > Now to make stateful firewall with NAT you need to make some not very > "readable" tricks to record state ("allow") of outbound connection > before NAT, but pass packet to NAT after that. I know two: > > (a) skipto-nat-allow pattern from many HOWOTOs Lev, can you provide references for these HOWTOs you refer to? I have a suspicion that some of them should be taken out and shot. cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 3 10:24:26 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0DFF3136; Tue, 3 Feb 2015 10:24:26 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id C29B0357; Tue, 3 Feb 2015 10:24:25 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 1D6ED5C002; Tue, 3 Feb 2015 13:23:37 +0300 (MSK) Message-ID: <54D0A1AA.4080402@FreeBSD.org> Date: Tue, 03 Feb 2015 13:23:38 +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.4.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> In-Reply-To: <20150203205715.A38620@sola.nimnet.asn.au> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw , freebsd-net X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 10:24:26 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03.02.2015 13:04, Ian Smith wrote: >> Now to make stateful firewall with NAT you need to make some not >> very "readable" tricks to record state ("allow") of outbound >> connection before NAT, but pass packet to NAT after that. I know >> two: >> >> (a) skipto-nat-allow pattern from many HOWOTOs > > Lev, can you provide references for these HOWTOs you refer to? > > I have a suspicion that some of them should be taken out and shot. google for "FreeBSD ipfw nat stateful" :) There are lot of them. Not real HOWTOs, but blog posts & alike. BTW, without new mechanism it is really hard to do such firewall, as we need action (nat) after "allow keep-state". It could be done with this ugly skip-to or with "allow keep-state" in INCOMING section of firewall, what is not much better, as I prefer to decide let packet out or not in OUTCOMING part of firewall and with "allow keep-state" in incoming path it flood state table with unused states. Another problem, that "keep-state" acts as "check-state" too, so you could not have ANOTHER "keep-state" before NAT in outgoing part or you miss nat completely (sate is created in outgoing path, and then checked before nat in outgoing path with "keep-state", grrrrr, ugly!). - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0KGqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePYvYQALeGCF9EuZKP3jLDaRwad+TO IhYq5I3xPPqU3eNEdQ6OqdFonVQ4mDB+UipZzspC/U5drf1qo2LkOF8oBNDlVDW4 2I+bgYStptIkpSoBOe5AGRYwO3jfec77GvXhR8cMeQZK2Z9NIazn5ZtFkdQyiiDU +b7pxBQ0SbbMUT3hubl4H+v93dMGfjnzrFg1aSY4/uYnmilb8plWN1o4BshZVMSz z1lrFSaorj4RNYxnpM6f6YtDDYx4TahA7+OILl/BvzmNoztWb5hKNX+1TGLZPcch QE19iix+8O75yuVEMim6FxZ7u6sRk+4PpL/WzCLC2PpPxP/AyiFRh4zw7Q34HDNm xPe4Nfzt5vDj0/2HYMY0q0UeSfVY/U0iB3TWmV/3HFObaLeibCgHqOFGmtCpHw5/ EXJX36mpffO1wI6ImPAvQ9C/wE6/JdoL8R3EPrsN3hdNmoVNIrnDuaeAwiQM6Ljm 4CHzsqlYYzyjzgyMmmJahaZ3Lrr0IjnVixC3/z46SfpPipaua8Pr+oZozC4WFmnn 4IhsXH+XK7fTbKQaZML6o9j6Bm0hs9g6mt+VSWCYWGCHh/V3DzTuH2BECUeC8lsD 9pwHv4x4vPbh7d/kBwAl75mOe3etb8nD/+i+x0oqbPn0T73DgdGgYPnIKqElOi4Y Ws6uw/Euno3YnSSds5Eb =FJZe -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 3 10:26:58 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1B8D920F; Tue, 3 Feb 2015 10:26:58 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id D021F36F; Tue, 3 Feb 2015 10:26:57 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id E79945C002; Tue, 3 Feb 2015 13:26:26 +0300 (MSK) Message-ID: <54D0A253.1080302@FreeBSD.org> Date: Tue, 03 Feb 2015 13:26:27 +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.4.0 MIME-Version: 1.0 To: Julian Elischer , freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <54D06E5C.3090701@freebsd.org> <54D0951F.2000304@FreeBSD.org> In-Reply-To: <54D0951F.2000304@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 10:26:58 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03.02.2015 12:30, Lev Serebryakov wrote: > "keep-state". Problem is, it adds "if" branch for EACH action (in > kernel code). IMHO, it is very prohibitive. I've though about > that, but decide it is too expensive to have "if (!iHaveRecordOnly > || fromDynamic)" for EACH action, always. It could be done easily, > of course. Oh, I'm stupid! I know how to do "keep-state-only" cheap for fast path! I'll prepare new patch today or tomorrow. Also, I BADLY want "keep-state-but-dont-check" one. Sometimes it adds couple of "skipto" rules to avoid "keep-state" because it will trigger check too, even if MATCH will fail. - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0KJTXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTEMP/R3MZ8AmqKA0h7pFPy5SCwjT /zhnjjRvk+sDpc5BJPA/xIXV8IBupCPBCDR8CvCcqbaxFBECTTbW+JHCaHB0idXf F7lI2fTjiXcx5EK3E1RkjJ8dbRuHLAiYttMA4e1YIZBidsflgX/wLIEexseeia1K Vqh0NLofJLgzZET+wDbDBNncgWSaUnyJyW05BtVDUi/kpHekpZg4zm71gfWAoLgl tROv3i0y1YfkulwzZ84BcegsEAPMqD11AhSYZayeF1Ozl5jBGXTpC4rhaOQNYl7n +Hcr828rOZFiP/b4p/QhHx0TAMdYm3oqxSXMtr8GzWK+q5cClk7vdBv2Nj2W5f43 jOaJhDHgy21HxKCmFKKvSg/ZMb43F21ZHh0hU4eVlAK+AH74cli8hISTzZo4KxwC g74vUIPQkKs177UB+Hx1ADxwmur9fzbJpWWcK5zd/bLKQ8klUfiVrXp4awqLHma5 z6mKH89pxG9IC8rHFODetgfyvCJCiI0VY8bYuR8zJ6ciyk4NLGVhLk/VlzPyap8Y IT8O+kYLCaOWPbJvR+Zqti+hnvsk+5JnGxa16tVUkxXiJfh7VfWt9dDQ12Z9At1t srjr79R9yEJ0aPYKZRT4Z3q+CPhJZ+TpZyCxX3QT0vJuzewrj+R0CwSPP2xaWUZ3 x+Z6nsvc0bx37IgR7vsx =DlMK -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 3 10:42:55 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4EED9788 for ; Tue, 3 Feb 2015 10:42:55 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 11506797 for ; Tue, 3 Feb 2015 10:42:55 +0000 (UTC) Received: from [192.168.135.70] (unknown [94.19.235.70]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id B47505C002 for ; Tue, 3 Feb 2015 13:42:43 +0300 (MSK) Message-ID: <54D0A623.6020009@FreeBSD.org> Date: Tue, 03 Feb 2015 13:42:43 +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.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: "reass all from any to any" kills IPv6 packets Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 10:42:55 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Recommended "reass all from any to any in" kills all incoming IPv6 packets (at least, packets from 6in4 tunnel). "reass ip4 from any to any in" works as expected. Is it documentation bug or implementation bug? - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0KYjXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePAtwP+wX5m8V2lqQfpoHAeCcje4M/ 4pB4io/aNxvHQXevLqJl1kRCry9yvteUwJhnPKuBIov9OsNsGh2xe8t+JJh1JtIS 7qusKQpt17+QfW+t28m1p6p2bNLDa40NLDffaUOI5ClqXsiZf+vVhSs5Oyf9a2QB PcQ+y+kOgl/LodSfl1D5xI5mlVrJ5Pjz61+ShzPWyNB6aXjrz+FN13b5+YQll0AV GN4nKDw+aqSOQtFxcomaF2qch0Wn5zJ9Q+fyMjslW6Ze8/oVYV4gmzhl0XOYY//h 6GLk2kavrxCO8IaWANEqYbF9t64C95WSkWVeTqICPHoxs5Wvy6wlnyw4f0qRevR9 UzCn5Z/Oe2GbAvjr0p/6h+PlXnT99Rhnl0k14WMpjlPtH3hasi0tdHrJfm63dTu7 hutZol1nfzOXwrooBA9QCE8QV0flRau4GR/Qf/2PDQmtv3zcF1y6ThanTYX2sGRl hBdcvohzicG/P0W9jAPkiCI1fd23bi2goLo/Q7GtScKBjegpRNSH1sWbNyRHFUm7 5X9KIONK+2aZbIFseyyfGD4+pb5vMZQwqgXXAH5NkBNbyRwll3QnaaNv8Rqx6zNy 9Mkyn2RInWjr+bYqPHH8kB50SunPI5Hjx/7vc/ScMV0BbllqiUriYbOsSKadIUqf B4JONNRMRU0ZEwBWi71J =j4f0 -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 3 12:32:06 2015 Return-Path: Delivered-To: freebsd-ipfw@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1BD797F1; Tue, 3 Feb 2015 12:32:06 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4F8F3606; Tue, 3 Feb 2015 12:32:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t13CVwed078133; Tue, 3 Feb 2015 23:31:59 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 3 Feb 2015 23:31:58 +1100 (EST) From: Ian Smith To: Lev Serebryakov Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny In-Reply-To: <54D0A1AA.4080402@FreeBSD.org> Message-ID: <20150203231410.Y38620@sola.nimnet.asn.au> References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw , freebsd-net X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 12:32:06 -0000 On Tue, 3 Feb 2015 13:23:38 +0300, Lev Serebryakov wrote: > On 03.02.2015 13:04, Ian Smith wrote: > > >> Now to make stateful firewall with NAT you need to make some not > >> very "readable" tricks to record state ("allow") of outbound > >> connection before NAT, but pass packet to NAT after that. I know > >> two: > >> > >> (a) skipto-nat-allow pattern from many HOWOTOs > > > > Lev, can you provide references for these HOWTOs you refer to? > > > > I have a suspicion that some of them should be taken out and shot. > > google for "FreeBSD ipfw nat stateful" :) There are lot of them. Not > real HOWTOs, but blog posts & alike. As I suspected, most of them either are or refer to or are based on the handbook IPFW page, which I believe has caused more damage to the cause of IPFW adoption and usage than anything else. ipfw(8) is your friend, and pretty much your only friend in this regard. Of those, https://nileshgr.com/2014/12/07/freebsd-ipfw-nat-jails isn't bad. Many of the others are up to 10 years old and not much help. http://www.pl.freebsd.org/doc/handbook/firewalls-ipfw.html is an earlier version of https://www.freebsd.org/doc/handbook/firewalls-ipfw.html which has undergone significant improvement lately (compare), but still contains factual errors in the rulesets and very muddle-headed ideas regarding syslog and other things, IMHO. I'd best say no more on this topic; you can't discombobulate confusion. Cheers, Ian out > BTW, without new mechanism it is really hard to do such firewall, as > we need action (nat) after "allow keep-state". It could be done with > this ugly skip-to or with "allow keep-state" in INCOMING section of > firewall, what is not much better, as I prefer to decide let packet > out or not in OUTCOMING part of firewall and with "allow keep-state" > in incoming path it flood state table with unused states. > > Another problem, that "keep-state" acts as "check-state" too, so you > could not have ANOTHER "keep-state" before NAT in outgoing part or you > miss nat completely (sate is created in outgoing path, and then > checked before nat in outgoing path with "keep-state", grrrrr, ugly!). > > > - -- > // Lev Serebryakov AKA Black Lion From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 3 16:13:33 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3043A14A; Tue, 3 Feb 2015 16:13:33 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id C4A31608; Tue, 3 Feb 2015 16:13:32 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 2CD2C5C002; Tue, 3 Feb 2015 19:13:16 +0300 (MSK) Message-ID: <54D0F39B.4070707@FreeBSD.org> Date: Tue, 03 Feb 2015 19:13:15 +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.4.0 MIME-Version: 1.0 To: freebsd-ipfw , freebsd-net Subject: [RFC][patch] New "keep-state-only" option Content-Type: multipart/mixed; boundary="------------050009060301010507000304" Cc: julian@freebsd.org, melifaro@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 16:13:33 -0000 This is a multi-part message in MIME format. --------------050009060301010507000304 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Ok, "allow-state"/"deny-state" was very limited idea. Here is more universal mechanism: new "keep-state-only" (aliased as "record-only") option, which works exactly as "keep-state" BUT cancel match of rule after state creation. It allows to write stateful + nat firewall as easy as: nat 1 config if outIface 1000 skipto 2000 in skipto 3000 out deny all from any to any // Safeguard 2000 skipto 4000 recv inIface skipto 6000 recv outIface deny all from any to any // Safeguard 3000 skipto 5000 xmit inIface skipto 7000 xmit outIface deny all from any to any // Safeguard 4000 // For sake of simplicity! // Real firewall will have some checks about local network here allow all from any to any deny all from any to any // Safeguard 5000 // For sake of simplicity! // Real firewall will have some checks about local network here allow all from any to any deny all from any to any // Safeguard 6000 deny all not dst-ip $EXT_IP nat 1 all from any to any // All enabled with "keep-state-only" at block 7000 before NAT check-state all from any to any // Here could be accept rules for our servers or servers in DMZ // Disable everything else deny all from any to any 7000 // Here goes rules which could DISABLE outbound external traffic // Create state for "check-state" at block 6000 and fallthrough allow keep-state-only allow src-ip $EXT_IP // Save NAT some work nat 1 all from any to any allow all from any to any deny all from any to any // Safeguard And variants with multiple NATs and "nat global" becomes as easy as this, too! No stupid "skipto", no "keep-state" at "incoming from local network" parts of firewall, nothing! P.S. I HATE this "all any to any" part! - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0POaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePR+gP/1Oxi+h7pi0UlnqfrKyfHJRS FUbrMNeR9NATnTwxIK1UxNT1kF3m7wiwnFlgwW7rwLtTviFB1wK/pfd38l2h4t/w qUbtyK4PFMCq8I6wAJIB0qUl3C/mN1rwc+LSJJyFM07R52snoQs6FvkIYkCz0fOy Cak1f/P+scc21IRhFvYJXMMDO/1Y1nkxZk/HdHbn1GELpTXuHugvL1T9hHl98sqO HKlHnvtqAVlyZn9Sv3uC9nsyjFA2sdOCtb67UGnPDV3CIs4Jwj5CSst5jbz13qFG aXF8ZSm0coPJMUjH1PSogZM9Xiq23yZ47V0mesBxQsHL24548jM/wKcsR3buDjP7 NJ2rqo2OBCzTu6VCK2oIY5j9A6vq1mu8+/eBs5jF4C2k0xHiw53Okou7zOCA0gJ+ z+VGZvD3la/+tFjacty7Ra7LLNA8kNCnRa0QML7LOJ1/99a4l3Z/uGFxy5zYnk7d p27Y85CAhTJQjkYZSGAiFD5SE4XxRqtSJ9OL89w7vLxoHqW0rqwi+DVrr9uvXQZS 8Z5G5iQARG4ygXuKsl6MlwChCXa3ucbOs41lorrug94cuVCwGg859zBZY3dpQsKz XIhtVQS21wPLxXywzIc678ar4uKVWNiaRWg+k57O7375gAszvqujRuTEcfHRf/T+ gHJJZt8Tc+en4bw8XItY =wOAJ -----END PGP SIGNATURE----- --------------050009060301010507000304 Content-Type: text/plain; charset=windows-1251; name="ipfw-state-only.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-only.diff" SW5kZXg6IHNiaW4vaXBmdy9pcGZ3LjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3L2lw ZncuOAkocmV2aXNpb24gMjc4MTUxKQorKysgc2Jpbi9pcGZ3L2lwZncuOAkod29ya2luZyBj b3B5KQpAQCAtMTY2LDcgKzE2Niw4IEBACiBkZXBlbmRpbmcgb24gaG93IHRoZSBrZXJuZWwg aXMgY29uZmlndXJlZC4KIC5QcAogSWYgdGhlIHJ1bGVzZXQgaW5jbHVkZXMgb25lIG9yIG1v cmUgcnVsZXMgd2l0aCB0aGUKLS5DbSBrZWVwLXN0YXRlCisuQ20ga2VlcC1zdGF0ZSAsCisu Q20ga2VlcC1zdGF0ZS1vbmx5CiBvcgogLkNtIGxpbWl0CiBvcHRpb24sCkBAIC0xODAsNyAr MTgxLDggQEAKIER5bmFtaWMgcnVsZXMsIHdoaWNoIGhhdmUgYSBsaW1pdGVkIGxpZmV0aW1l LCBhcmUgY2hlY2tlZAogYXQgdGhlIGZpcnN0IG9jY3VycmVuY2Ugb2YgYQogLkNtIGNoZWNr LXN0YXRlICwKLS5DbSBrZWVwLXN0YXRlCisuQ20ga2VlcC1zdGF0ZSAsCisuQ20ga2VlcC1z dGF0ZS1vbmx5CiBvcgogLkNtIGxpbWl0CiBydWxlLCBhbmQgYXJlIHR5cGljYWxseSB1c2Vk IHRvIG9wZW4gdGhlIGZpcmV3YWxsIG9uLWRlbWFuZCB0bwpAQCAtNTgyLDcgKzU4NCw4IEBA CiBwYWNrZXQgZGVsaXZlcnkuCiAuUHAKIE5vdGU6IHRoaXMgY29uZGl0aW9uIGlzIGNoZWNr ZWQgYmVmb3JlIGFueSBvdGhlciBjb25kaXRpb24sIGluY2x1ZGluZwotb25lcyBzdWNoIGFz IGtlZXAtc3RhdGUgb3IgY2hlY2stc3RhdGUgd2hpY2ggbWlnaHQgaGF2ZSBzaWRlIGVmZmVj dHMuCitvbmVzIHN1Y2ggYXMga2VlcC1zdGF0ZSwga2VlcC1zdGF0LW9ubHkgb3IgY2hlY2st c3RhdGUgd2hpY2ggbWlnaHQgaGF2ZQorc2lkZSBlZmZlY3RzLgogLkl0IENtIGxvZyBPcCBD bSBsb2dhbW91bnQgQXIgbnVtYmVyCiBQYWNrZXRzIG1hdGNoaW5nIGEgcnVsZSB3aXRoIHRo ZQogLkNtIGxvZwpAQCAtNzQ4LDcgKzc1MSw4IEBACiBJZiBubwogLkNtIGNoZWNrLXN0YXRl CiBydWxlIGlzIGZvdW5kLCB0aGUgZHluYW1pYyBydWxlc2V0IGlzIGNoZWNrZWQgYXQgdGhl IGZpcnN0Ci0uQ20ga2VlcC1zdGF0ZQorLkNtIGtlZXAtc3RhdGUgLAorLkNtIGtlZXAtc3Rh dGUtb25seSAsCiBvcgogLkNtIGxpbWl0CiBydWxlLgpAQCAtMTU4Myw2ICsxNTg3LDE0IEBA CiAuWHIgc3lzY3RsIDgKIHZhcmlhYmxlcyksIGFuZCB0aGUgbGlmZXRpbWUgaXMgcmVmcmVz aGVkIGV2ZXJ5IHRpbWUgYSBtYXRjaGluZwogcGFja2V0IGlzIGZvdW5kLgorLkl0IENtIGtl ZXAtc3RhdGUtb25seSB8IHJlY29yZC1vbmx5CitVcG9uIGEgbWF0Y2gsIHRoZSBmaXJld2Fs bCB3aWxsIGNyZWF0ZSBhIGR5bmFtaWMgcnVsZSBhcyBpZgorLkNtIGtlZXAtc3RhdGUKK3dh cyBzcGVjaWZpZWQsIGJ1dCBhZnRlciB0aGF0IG1hdGNoIGlzIGNhbmNlbGxlZCBhbmQgdGhl IHNlYXJjaAorY29udGludWVzIHdpdGggdGhlIG5leHQgcnVsZS4KK09uIGR5bmFtaWMgcnVs ZSBtYXRjaCBhY3Rpb24sIHNwZWNpZmllZCBpbiB0aGlzIHJ1bGUsCitwZXJmb3JtZWQgYXMg aWYgcnVsZSBjb250YWlucworLkNtIGtlZXAtc3RhdGUgLgogLkl0IENtIGxheWVyMgogTWF0 Y2hlcyBvbmx5IGxheWVyMiBwYWNrZXRzLCBpLmUuLCB0aG9zZSBwYXNzZWQgdG8KIC5ObQpJ bmRleDogc2Jpbi9pcGZ3L2lwZncyLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3L2lw ZncyLmMJKHJldmlzaW9uIDI3ODE1MSkKKysrIHNiaW4vaXBmdy9pcGZ3Mi5jCSh3b3JraW5n IGNvcHkpCkBAIC0yOTIsNiArMjkyLDggQEAKIAl7ICJpbiIsCQkJVE9LX0lOIH0sCiAJeyAi bGltaXQiLAkJVE9LX0xJTUlUIH0sCiAJeyAia2VlcC1zdGF0ZSIsCQlUT0tfS0VFUFNUQVRF IH0sCisJeyAicmVjb3JkLXN0YXRlIiwJVE9LX1NUQVRFX09OTFkgfSwKKwl7ICJrZWVwLXN0 YXRlLW9ubHkiLAlUT0tfU1RBVEVfT05MWSB9LAogCXsgImJyaWRnZWQiLAkJVE9LX0xBWUVS MiB9LAogCXsgImxheWVyMiIsCQlUT0tfTEFZRVIyIH0sCiAJeyAib3V0IiwJCVRPS19PVVQg fSwKQEAgLTE5OTMsNiArMTk5NSwxMCBAQAogCQkJCWJwcmludGYoYnAsICIga2VlcC1zdGF0 ZSIpOwogCQkJCWJyZWFrOwogCisJCQljYXNlIE9fU1RBVEVfT05MWToKKwkJCQlicHJpbnRm KGJwLCAiIGtlZXAtc3RhdGUtb25seSIpOworCQkJCWJyZWFrOworCiAJCQljYXNlIE9fTElN SVQ6IHsKIAkJCQlzdHJ1Y3QgX3NfeCAqcCA9IGxpbWl0X21hc2tzOwogCQkJCWlwZndfaW5z bl9saW1pdCAqYyA9IChpcGZ3X2luc25fbGltaXQgKiljbWQ7CkBAIC00MzM1LDE0ICs0MzQx LDE2IEBACiAJCQlicmVhazsKIAogCQljYXNlIFRPS19LRUVQU1RBVEU6CisJCWNhc2UgVE9L X1NUQVRFX09OTFk6CiAJCQlpZiAob3Blbl9wYXIpCi0JCQkJZXJyeChFWF9VU0FHRSwgImtl ZXAtc3RhdGUgY2Fubm90IGJlIHBhcnQgIgorCQkJCWVycngoRVhfVVNBR0UsICJrZWVwLXN0 YXRlIG9yIGtlZXAtc3RhdGUtb25seSBjYW5ub3QgYmUgcGFydCAiCiAJCQkJICAgICJvZiBh biBvciBibG9jayIpOwogCQkJaWYgKGhhdmVfc3RhdGUpCiAJCQkJZXJyeChFWF9VU0FHRSwg Im9ubHkgb25lIG9mIGtlZXAtc3RhdGUgIgogCQkJCQkiYW5kIGxpbWl0IGlzIGFsbG93ZWQi KTsKIAkJCWhhdmVfc3RhdGUgPSBjbWQ7Ci0JCQlmaWxsX2NtZChjbWQsIE9fS0VFUF9TVEFU RSwgMCwgMCk7CisJCQlmaWxsX2NtZChjbWQsIGkgPT0gVE9LX0tFRVBTVEFURSA/CisJCQkJ T19LRUVQX1NUQVRFIDogT19TVEFURV9PTkxZLCAwLCAwKTsKIAkJCWJyZWFrOwogCiAJCWNh c2UgVE9LX0xJTUlUOiB7CkBAIC00NTg1LDcgKzQ1OTMsNyBAQAogCQlkc3QgPSBuZXh0X2Nt ZChkc3QsICZyYmxlbik7CiAJfQogCi0JLyogY29weSBhbGwgY29tbWFuZHMgYnV0IE9fTE9H LCBPX0tFRVBfU1RBVEUsIE9fTElNSVQsIE9fQUxUUSwgT19UQUcgKi8KKwkvKiBjb3B5IGFs bCBjb21tYW5kcyBidXQgT19MT0csIE9fS0VFUF9TVEFURSwgT19TVEFURV9PTkxZLCBPX0xJ TUlULCBPX0FMVFEsIE9fVEFHICovCiAJZm9yIChzcmMgPSAoaXBmd19pbnNuICopY21kYnVm OyBzcmMgIT0gY21kOyBzcmMgKz0gaSkgewogCQlpID0gRl9MRU4oc3JjKTsKIAkJQ0hFQ0tf UkJVRkxFTihpKTsKQEAgLTQ1OTMsNiArNDYwMSw3IEBACiAJCXN3aXRjaCAoc3JjLT5vcGNv ZGUpIHsKIAkJY2FzZSBPX0xPRzoKIAkJY2FzZSBPX0tFRVBfU1RBVEU6CisJCWNhc2UgT19T VEFURV9PTkxZOgogCQljYXNlIE9fTElNSVQ6CiAJCWNhc2UgT19BTFRROgogCQljYXNlIE9f VEFHOgpJbmRleDogc2Jpbi9pcGZ3L2lwZncyLmgKPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9p cGZ3L2lwZncyLmgJKHJldmlzaW9uIDI3ODE1MSkKKysrIHNiaW4vaXBmdy9pcGZ3Mi5oCSh3 b3JraW5nIGNvcHkpCkBAIC0yMjcsNiArMjI3LDcgQEAKIAlUT0tfTE9DSywKIAlUT0tfVU5M T0NLLAogCVRPS19WTElTVCwKKwlUT0tfU1RBVEVfT05MWSwKIH07CiAKIC8qCkluZGV4OiBz eXMvbmV0aW5ldC9pcF9mdy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0L2lwX2Z3 LmgJKHJldmlzaW9uIDI3ODE1MSkKKysrIHN5cy9uZXRpbmV0L2lwX2Z3LmgJKHdvcmtpbmcg Y29weSkKQEAgLTI1Miw2ICsyNTIsOCBAQAogCU9fRFNDUCwJCQkvKiAyIHUzMiA9IERTQ1Ag bWFzayAqLwogCU9fU0VURFNDUCwJCS8qIGFyZzE9RFNDUCB2YWx1ZSAqLwogCU9fSVBfRkxP V19MT09LVVAsCS8qIGFyZzE9dGFibGUgbnVtYmVyLCB1MzI9dmFsdWUJKi8KKwkKKwlPX1NU QVRFX09OTFksCQkvKiBub25lCQkJCSovCiAKIAlPX0xBU1RfT1BDT0RFCQkvKiBub3QgYW4g b3Bjb2RlIQkJKi8KIH07CkluZGV4OiBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3Mi5jCj09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT0KLS0tIHN5cy9uZXRwZmlsL2lwZncvaXBfZncyLmMJKHJldmlzaW9uIDI3ODE1 MSkKKysrIHN5cy9uZXRwZmlsL2lwZncvaXBfZncyLmMJKHdvcmtpbmcgY29weSkKQEAgLTIx MDcsOSArMjEwNyw5IEBACiAJCQkgKiBPX1RBRywgT19MT0cgYW5kIE9fQUxUUSBhY3Rpb24g cGFyYW1ldGVyczoKIAkJCSAqICAgcGVyZm9ybSBzb21lIGFjdGlvbiBhbmQgc2V0IG1hdGNo ID0gMTsKIAkJCSAqCi0JCQkgKiBPX0xJTUlUIGFuZCBPX0tFRVBfU1RBVEU6IHRoZXNlIG9w Y29kZXMgYXJlCi0JCQkgKiAgIG5vdCByZWFsICdhY3Rpb25zJywgYW5kIGFyZSBzdG9yZWQg cmlnaHQKLQkJCSAqICAgYmVmb3JlIHRoZSAnYWN0aW9uJyBwYXJ0IG9mIHRoZSBydWxlLgor CQkJICogT19MSU1JVCwgT19LRUVQX1NUQVRFIGFuZCBPX1NUQVRFX09OTFk6IHRoZXNlCisJ CQkgKiAgIG9wY29kZXMgYXJlIG5vdCByZWFsICdhY3Rpb25zJywgYW5kIGFyZSBzdG9yZWQK KwkJCSAqICAgcmlnaHQgYmVmb3JlIHRoZSAnYWN0aW9uJyBwYXJ0IG9mIHRoZSBydWxlLgog CQkJICogICBUaGVzZSBvcGNvZGVzIHRyeSB0byBpbnN0YWxsIGFuIGVudHJ5IGluIHRoZQog CQkJICogICBzdGF0ZSB0YWJsZXM7IGlmIHN1Y2Nlc3NmdWwsIHdlIGNvbnRpbnVlIHdpdGgK IAkJCSAqICAgdGhlIG5leHQgb3Bjb2RlIChtYXRjaD0xOyBicmVhazspLCBvdGhlcndpc2UK QEAgLTIxMjYsOSArMjEyNiwyMCBAQAogCQkJICogICBmdXJ0aGVyIGluc3RhbmNlcyBvZiB0 aGVzZSBvcGNvZGVzIGJlY29tZSBOT1BzLgogCQkJICogICBUaGUganVtcCB0byB0aGUgbmV4 dCBydWxlIGlzIGRvbmUgYnkgc2V0dGluZwogCQkJICogICBsPTAsIGNtZGxlbj0wLgorCQkJ ICoKKwkJCSAqIE9fU1RBVEVfT05MWTogdGhpcyBvcGNvZGUgaXMgbm90IHJlYWwgJ2FjdGlv bicKKwkJCSAqICB0b28sIGFuZCBpcyBzdG9yZWQgcmlnaHQgYmVmb3JlIHRoZSAnYWN0aW9u JworCQkJICogIHBhcnQgb2YgdGhlIHJ1bGUsIHJpZ2h0IGFmdGVyIE9fS0VFUF9TVEFURQor CQkJICogIG9wY29kZS4gSXQgY2F1c2VzIG1hdGNoIGZhaWx1cmUgc28gcmVhbAorCQkJICog ICdhY3Rpb24nIGNvdWxkIGJlIGV4ZWN1dGVkIG9ubHkgaWYgcnVsZQorCQkJICogIGlzIGNo ZWNrZWQgdmlhIGR5bmFtaWMgcnVsZSBmcm9tIHN0YXRlCisJCQkgKiAgdGFibGUsIGFzIGlu IHN1Y2ggY2FzZSBleGVjdXRpb24gc3RhcnRzCisJCQkgKiAgZnJvbSB0cnVlICdhY3Rpb24n IG9wY29kZSBkaXJlY3RseS4KKwkJCSAqICAgCiAJCQkgKi8KIAkJCWNhc2UgT19MSU1JVDoK IAkJCWNhc2UgT19LRUVQX1NUQVRFOgorCQkJY2FzZSBPX1NUQVRFX09OTFk6CiAJCQkJaWYg KGlwZndfaW5zdGFsbF9zdGF0ZShjaGFpbiwgZiwKIAkJCQkgICAgKGlwZndfaW5zbl9saW1p dCAqKWNtZCwgYXJncywgdGFibGVhcmcpKSB7CiAJCQkJCS8qIGVycm9yIG9yIGxpbWl0IHZp b2xhdGlvbiAqLwpAQCAtMjEzNiw3ICsyMTQ3LDExIEBACiAJCQkJCWwgPSAwOwkvKiBleGl0 IGlubmVyIGxvb3AgKi8KIAkJCQkJZG9uZSA9IDE7IC8qIGV4aXQgb3V0ZXIgbG9vcCAqLwog CQkJCX0KLQkJCQltYXRjaCA9IDE7CisJCQkJaWYgKGNtZC0+b3Bjb2RlID09IE9fU1RBVEVf T05MWSkgeworCQkJCQlsID0gMDsJLyogZXhpdCBpbm5lciBsb29wICovCisJCQkJCW1hdGNo ID0gMDsKKwkJCQl9IGVsc2UKKwkJCQkJbWF0Y2ggPSAxOwogCQkJCWJyZWFrOwogCiAJCQlj YXNlIE9fUFJPQkVfU1RBVEU6CkBAIC0yMTg4LDYgKzIyMDMsNyBAQAogCQkJCWJyZWFrOwog CiAJCQljYXNlIE9fQUNDRVBUOgorCiAJCQkJcmV0dmFsID0gMDsJLyogYWNjZXB0ICovCiAJ CQkJbCA9IDA7CQkvKiBleGl0IGlubmVyIGxvb3AgKi8KIAkJCQlkb25lID0gMTsJLyogZXhp dCBvdXRlciBsb29wICovCkBAIC0yNTM3LDcgKzI1NTMsNyBAQAogCQkJCWRvbmUgPSAxOwkv KiBleGl0IG91dGVyIGxvb3AgKi8KIAkJCQlicmVhazsKIAkJCX0KLQorCQkJCiAJCQlkZWZh dWx0OgogCQkJCXBhbmljKCItLSB1bmtub3duIG9wY29kZSAlZFxuIiwgY21kLT5vcGNvZGUp OwogCQkJfSAvKiBlbmQgb2Ygc3dpdGNoKCkgb24gb3Bjb2RlcyAqLwpJbmRleDogc3lzL25l dHBmaWwvaXBmdy9pcF9md19keW5hbWljLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldHBm aWwvaXBmdy9pcF9md19keW5hbWljLmMJKHJldmlzaW9uIDI3ODE1MSkKKysrIHN5cy9uZXRw ZmlsL2lwZncvaXBfZndfZHluYW1pYy5jCSh3b3JraW5nIGNvcHkpCkBAIC03MDgsNiArNzA4 LDcgQEAKIAogCXN3aXRjaCAoY21kLT5vLm9wY29kZSkgewogCWNhc2UgT19LRUVQX1NUQVRF OgkvKiBiaWRpciBydWxlICovCisJY2FzZSBPX1NUQVRFX09OTFk6CiAJCXEgPSBhZGRfZHlu X3J1bGUoJmFyZ3MtPmZfaWQsIGksIE9fS0VFUF9TVEFURSwgcnVsZSk7CiAJCWJyZWFrOwog CkBAIC0xMzU3LDYgKzEzNTgsNyBAQAogCQlzd2l0Y2ggKGNtZC0+b3Bjb2RlKSB7CiAJCWNh c2UgT19MSU1JVDoKIAkJY2FzZSBPX0tFRVBfU1RBVEU6CisJCWNhc2UgT19TVEFURV9PTkxZ OgogCQljYXNlIE9fUFJPQkVfU1RBVEU6CiAJCWNhc2UgT19DSEVDS19TVEFURToKIAkJCXJl dHVybiAoMSk7CkluZGV4OiBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3NvY2tvcHQuYwo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09Ci0tLSBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3NvY2tvcHQuYwkocmV2aXNp b24gMjc4MTUxKQorKysgc3lzL25ldHBmaWwvaXBmdy9pcF9md19zb2Nrb3B0LmMJKHdvcmtp bmcgY29weSkKQEAgLTE0MzMsNiArMTQzMyw3IEBACiAJCXN3aXRjaCAoY21kLT5vcGNvZGUp IHsKIAkJY2FzZSBPX1BST0JFX1NUQVRFOgogCQljYXNlIE9fS0VFUF9TVEFURToKKwkJY2Fz ZSBPX1NUQVRFX09OTFk6CiAJCWNhc2UgT19QUk9UTzoKIAkJY2FzZSBPX0lQX1NSQ19NRToK IAkJY2FzZSBPX0lQX0RTVF9NRToK --------------050009060301010507000304 Content-Type: application/octet-stream; name="ipfw-state-only.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-only.diff.sig" iQJ8BAABCgBmBQJU0POaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3Au ZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFFQUIwM0M1OEJGREM0 NzhGAAoJEOqwPFi/3EeP+IYP/34Ksov2rvdf1N29a/AjpP64aqeG78LcIeiSem9Ai4s0P3tB xNQfUSmSUZh6C2wsRCxXP6ee3oMOSc4jbETBaedYHU446I0iX/GvD04SvHyyramYf+nU3gXq SF7GF5DbN3XHfqpihunaijLLZQz6zhwLuwPPSeLFG2xccc4o/8M+P6UHbyLDQNfOHR9YefmK 4bS7llfioqcDwb2bvmcD07wAXCxcKDzkefRcq3qyaPkIwxQ+A1CiTtyySpk6HjvEs1VogKRk 5iZbcAszmLMemIpXTUwNrScGaeCrnyCatAjtKTe9u26VI7X0XRP633a+/E/C7JJ6gHgWrmXF E9XVuaz7lWbjdsIlyGi1AW7fjzUxPCBoLopnwpqL0d3WX43OykR0U/x8euizlseGjnd13sWn Oly5i9SZAPJzvwR4F9wtmBgbHxqZu6fn1uC0xQPcjJsz/lsRno0lVFCUzmGNwPKJS4xvUSaq FfET86rxuzVQUhRHGupzMsqlKtAa7DTD/RSwVh05CMtoiGao7KR46nmly6fccGY4a2Gsvphh vR/xi4AdyqA/0+hPokBr/br1CGUZ72IkFs7h4tbG1u6Y2J1BED+hLb3ccOThTovQW9JCkK6l Osgt9KrWxAWsavIpTWljlWni8fi6cEULZGclx9yKUBizx/ht+8gHE+cj9xdy --------------050009060301010507000304-- From owner-freebsd-ipfw@FreeBSD.ORG Tue Feb 3 16:56:07 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 147ACCC1; Tue, 3 Feb 2015 16:56:07 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 9050499B; Tue, 3 Feb 2015 16:56:06 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 273055C002; Tue, 3 Feb 2015 19:55:57 +0300 (MSK) Message-ID: <54D0FD9B.5000108@FreeBSD.org> Date: Tue, 03 Feb 2015 19:55:55 +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.4.0 MIME-Version: 1.0 To: freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] New "keep-state-only" option (version 2) References: <54D0F39B.4070707@FreeBSD.org> In-Reply-To: <54D0F39B.4070707@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------050501000709010809070907" Cc: melifaro@FreeBSD.org, julian@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Feb 2015 16:56:07 -0000 This is a multi-part message in MIME format. --------------050501000709010809070907 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03.02.2015 19:13, Lev Serebryakov wrote: > Ok, "allow-state"/"deny-state" was very limited idea. Here is more > universal mechanism: new "keep-state-only" (aliased as > "record-only") option, which works exactly as "keep-state" BUT > cancel match of rule after state creation. It allows to write > stateful + nat firewall as easy as: To work as expected, "keep-state-only" should not imply "check-state" in opposite to "keep-state". - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0P2bXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePkkoQAJHlybB+Hmcae64Bu5CyimWy FJsicjr/DkNLhzAVJAglslBqgEkSrN2CiYTaASMMTmg6bj8RL6LLHWm0v/bAYQQR lMGqCCcz+NvKjrB2D4egRYkA4NHGQ60Lj4O4YfsNOc9Jrsyn7RAqVc9vwMXT/GvN GmDgVqsgA+IWSNZ4flE/MbnkZ8tq/jztuxaQneeKq6qmT9HaiNN8QeNrecO0kghz GXZCXTGVgoguv4K/SDTkqcKapL7vP1mzRuR34FQcN/Mmj4lJ9Mdk2JNzIg0YHBZ+ HzvRvoNBHJfgw1G5ydORGOeIBgd5XCzlYTws2dboksLrd3taF4emDGjpvzn+Qwzd X7B2hRnSOByM5j8LfctO2E7Zj7zPDtVtlZ3YsCpKvWzCdtSthzQAlvB/iE9CBOis JAXbINONngevwwrWqCsZCxgXCGSrp9scGHY7Es02M2Pov6GSzXtPq1349SmFrH5I J/ijTfV8e0kNnwBHfy/jf5wpXNQSV93IqRwDNp5jG+0qtDL2ZZNhMamELauWhbhB nTJ+Og2TsPeOSp88/Jb6bW+pIsDQ7XIxdBNFC0j9lU/jFwNIfAK5xkvc239IsqeC ylQGghwiGl9E4P3yIhLa2OAUdCy9J+dw8ZlyBkS3pN27j/RIoyMvkAA5l8i6dVRR AEfyn36tKaR/BEUkGN5g =9avV -----END PGP SIGNATURE----- --------------050501000709010809070907 Content-Type: text/plain; charset=windows-1251; name="ipfw-state-only-v2.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-only-v2.diff" SW5kZXg6IHNiaW4vaXBmdy9pcGZ3LjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3L2lw ZncuOAkocmV2aXNpb24gMjc4MTUxKQorKysgc2Jpbi9pcGZ3L2lwZncuOAkod29ya2luZyBj b3B5KQpAQCAtMTY2LDcgKzE2Niw4IEBACiBkZXBlbmRpbmcgb24gaG93IHRoZSBrZXJuZWwg aXMgY29uZmlndXJlZC4KIC5QcAogSWYgdGhlIHJ1bGVzZXQgaW5jbHVkZXMgb25lIG9yIG1v cmUgcnVsZXMgd2l0aCB0aGUKLS5DbSBrZWVwLXN0YXRlCisuQ20ga2VlcC1zdGF0ZSAsCisu Q20ga2VlcC1zdGF0ZS1vbmx5CiBvcgogLkNtIGxpbWl0CiBvcHRpb24sCkBAIC01ODIsNyAr NTgzLDggQEAKIHBhY2tldCBkZWxpdmVyeS4KIC5QcAogTm90ZTogdGhpcyBjb25kaXRpb24g aXMgY2hlY2tlZCBiZWZvcmUgYW55IG90aGVyIGNvbmRpdGlvbiwgaW5jbHVkaW5nCi1vbmVz IHN1Y2ggYXMga2VlcC1zdGF0ZSBvciBjaGVjay1zdGF0ZSB3aGljaCBtaWdodCBoYXZlIHNp ZGUgZWZmZWN0cy4KK29uZXMgc3VjaCBhcyBrZWVwLXN0YXRlLCBrZWVwLXN0YXQtb25seSBv ciBjaGVjay1zdGF0ZSB3aGljaCBtaWdodCBoYXZlCitzaWRlIGVmZmVjdHMuCiAuSXQgQ20g bG9nIE9wIENtIGxvZ2Ftb3VudCBBciBudW1iZXIKIFBhY2tldHMgbWF0Y2hpbmcgYSBydWxl IHdpdGggdGhlCiAuQ20gbG9nCkBAIC0xNTgzLDYgKzE1ODUsMTggQEAKIC5YciBzeXNjdGwg OAogdmFyaWFibGVzKSwgYW5kIHRoZSBsaWZldGltZSBpcyByZWZyZXNoZWQgZXZlcnkgdGlt ZSBhIG1hdGNoaW5nCiBwYWNrZXQgaXMgZm91bmQuCisuSXQgQ20ga2VlcC1zdGF0ZS1vbmx5 IHwgcmVjb3JkLW9ubHkKK1Vwb24gYSBtYXRjaCwgdGhlIGZpcmV3YWxsIHdpbGwgY3JlYXRl IGEgZHluYW1pYyBydWxlIGFzIGlmCisuQ20ga2VlcC1zdGF0ZQord2FzIHNwZWNpZmllZCwg YnV0IGFmdGVyIHRoYXQgbWF0Y2ggaXMgY2FuY2VsbGVkIGFuZCB0aGUgc2VhcmNoCitjb250 aW51ZXMgd2l0aCB0aGUgbmV4dCBydWxlLgorT24gZHluYW1pYyBydWxlIG1hdGNoIGFjdGlv biwgc3BlY2lmaWVkIGluIHRoaXMgcnVsZSwKK3BlcmZvcm1lZCBhcyBpZiBydWxlIGNvbnRh aW5zCisuQ20ga2VlcC1zdGF0ZSAuCitUaGlzIG9wdGlvbiBkb2Vzbid0IGFjdCBhcworLkNt IGNoZWNrLXN0YXRlCitpbiBjb250cmFzdCB0bworLkNtIGtlZXAtc3RhdGUgLgogLkl0IENt IGxheWVyMgogTWF0Y2hlcyBvbmx5IGxheWVyMiBwYWNrZXRzLCBpLmUuLCB0aG9zZSBwYXNz ZWQgdG8KIC5ObQpJbmRleDogc2Jpbi9pcGZ3L2lwZncyLmMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g c2Jpbi9pcGZ3L2lwZncyLmMJKHJldmlzaW9uIDI3ODE1MSkKKysrIHNiaW4vaXBmdy9pcGZ3 Mi5jCSh3b3JraW5nIGNvcHkpCkBAIC0yOTIsNiArMjkyLDggQEAKIAl7ICJpbiIsCQkJVE9L X0lOIH0sCiAJeyAibGltaXQiLAkJVE9LX0xJTUlUIH0sCiAJeyAia2VlcC1zdGF0ZSIsCQlU T0tfS0VFUFNUQVRFIH0sCisJeyAicmVjb3JkLXN0YXRlIiwJVE9LX1NUQVRFX09OTFkgfSwK Kwl7ICJrZWVwLXN0YXRlLW9ubHkiLAlUT0tfU1RBVEVfT05MWSB9LAogCXsgImJyaWRnZWQi LAkJVE9LX0xBWUVSMiB9LAogCXsgImxheWVyMiIsCQlUT0tfTEFZRVIyIH0sCiAJeyAib3V0 IiwJCVRPS19PVVQgfSwKQEAgLTE5OTMsNiArMTk5NSwxMCBAQAogCQkJCWJwcmludGYoYnAs ICIga2VlcC1zdGF0ZSIpOwogCQkJCWJyZWFrOwogCisJCQljYXNlIE9fU1RBVEVfT05MWToK KwkJCQlicHJpbnRmKGJwLCAiIGtlZXAtc3RhdGUtb25seSIpOworCQkJCWJyZWFrOworCiAJ CQljYXNlIE9fTElNSVQ6IHsKIAkJCQlzdHJ1Y3QgX3NfeCAqcCA9IGxpbWl0X21hc2tzOwog CQkJCWlwZndfaW5zbl9saW1pdCAqYyA9IChpcGZ3X2luc25fbGltaXQgKiljbWQ7CkBAIC00 MzM1LDE0ICs0MzQxLDE2IEBACiAJCQlicmVhazsKIAogCQljYXNlIFRPS19LRUVQU1RBVEU6 CisJCWNhc2UgVE9LX1NUQVRFX09OTFk6CiAJCQlpZiAob3Blbl9wYXIpCi0JCQkJZXJyeChF WF9VU0FHRSwgImtlZXAtc3RhdGUgY2Fubm90IGJlIHBhcnQgIgorCQkJCWVycngoRVhfVVNB R0UsICJrZWVwLXN0YXRlIG9yIGtlZXAtc3RhdGUtb25seSBjYW5ub3QgYmUgcGFydCAiCiAJ CQkJICAgICJvZiBhbiBvciBibG9jayIpOwogCQkJaWYgKGhhdmVfc3RhdGUpCiAJCQkJZXJy eChFWF9VU0FHRSwgIm9ubHkgb25lIG9mIGtlZXAtc3RhdGUgIgogCQkJCQkiYW5kIGxpbWl0 IGlzIGFsbG93ZWQiKTsKIAkJCWhhdmVfc3RhdGUgPSBjbWQ7Ci0JCQlmaWxsX2NtZChjbWQs IE9fS0VFUF9TVEFURSwgMCwgMCk7CisJCQlmaWxsX2NtZChjbWQsIGkgPT0gVE9LX0tFRVBT VEFURSA/CisJCQkJT19LRUVQX1NUQVRFIDogT19TVEFURV9PTkxZLCAwLCAwKTsKIAkJCWJy ZWFrOwogCiAJCWNhc2UgVE9LX0xJTUlUOiB7CkBAIC00NTgwLDEyICs0NTg4LDEzIEBACiAJ LyoKIAkgKiBnZW5lcmF0ZSBPX1BST0JFX1NUQVRFIGlmIG5lY2Vzc2FyeQogCSAqLwotCWlm IChoYXZlX3N0YXRlICYmIGhhdmVfc3RhdGUtPm9wY29kZSAhPSBPX0NIRUNLX1NUQVRFKSB7 CisJaWYgKGhhdmVfc3RhdGUgJiYgaGF2ZV9zdGF0ZS0+b3Bjb2RlICE9IE9fQ0hFQ0tfU1RB VEUgJiYKKwkgICAgaGF2ZV9zdGF0ZS0+b3Bjb2RlICE9IE9fU1RBVEVfT05MWSkgewogCQlm aWxsX2NtZChkc3QsIE9fUFJPQkVfU1RBVEUsIDAsIDApOwogCQlkc3QgPSBuZXh0X2NtZChk c3QsICZyYmxlbik7CiAJfQogCi0JLyogY29weSBhbGwgY29tbWFuZHMgYnV0IE9fTE9HLCBP X0tFRVBfU1RBVEUsIE9fTElNSVQsIE9fQUxUUSwgT19UQUcgKi8KKwkvKiBjb3B5IGFsbCBj b21tYW5kcyBidXQgT19MT0csIE9fS0VFUF9TVEFURSwgT19TVEFURV9PTkxZLCBPX0xJTUlU LCBPX0FMVFEsIE9fVEFHICovCiAJZm9yIChzcmMgPSAoaXBmd19pbnNuICopY21kYnVmOyBz cmMgIT0gY21kOyBzcmMgKz0gaSkgewogCQlpID0gRl9MRU4oc3JjKTsKIAkJQ0hFQ0tfUkJV RkxFTihpKTsKQEAgLTQ1OTMsNiArNDYwMiw3IEBACiAJCXN3aXRjaCAoc3JjLT5vcGNvZGUp IHsKIAkJY2FzZSBPX0xPRzoKIAkJY2FzZSBPX0tFRVBfU1RBVEU6CisJCWNhc2UgT19TVEFU RV9PTkxZOgogCQljYXNlIE9fTElNSVQ6CiAJCWNhc2UgT19BTFRROgogCQljYXNlIE9fVEFH OgpJbmRleDogc2Jpbi9pcGZ3L2lwZncyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3 L2lwZncyLmgJKHJldmlzaW9uIDI3ODE1MSkKKysrIHNiaW4vaXBmdy9pcGZ3Mi5oCSh3b3Jr aW5nIGNvcHkpCkBAIC0yMjcsNiArMjI3LDcgQEAKIAlUT0tfTE9DSywKIAlUT0tfVU5MT0NL LAogCVRPS19WTElTVCwKKwlUT0tfU1RBVEVfT05MWSwKIH07CiAKIC8qCkluZGV4OiBzeXMv bmV0aW5ldC9pcF9mdy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0L2lwX2Z3LmgJ KHJldmlzaW9uIDI3ODE1MSkKKysrIHN5cy9uZXRpbmV0L2lwX2Z3LmgJKHdvcmtpbmcgY29w eSkKQEAgLTI1Miw2ICsyNTIsOCBAQAogCU9fRFNDUCwJCQkvKiAyIHUzMiA9IERTQ1AgbWFz ayAqLwogCU9fU0VURFNDUCwJCS8qIGFyZzE9RFNDUCB2YWx1ZSAqLwogCU9fSVBfRkxPV19M T09LVVAsCS8qIGFyZzE9dGFibGUgbnVtYmVyLCB1MzI9dmFsdWUJKi8KKwkKKwlPX1NUQVRF X09OTFksCQkvKiBub25lCQkJCSovCiAKIAlPX0xBU1RfT1BDT0RFCQkvKiBub3QgYW4gb3Bj b2RlIQkJKi8KIH07CkluZGV4OiBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3Mi5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIHN5cy9uZXRwZmlsL2lwZncvaXBfZncyLmMJKHJldmlzaW9uIDI3ODE1MSkK KysrIHN5cy9uZXRwZmlsL2lwZncvaXBfZncyLmMJKHdvcmtpbmcgY29weSkKQEAgLTIxMDcs OSArMjEwNyw5IEBACiAJCQkgKiBPX1RBRywgT19MT0cgYW5kIE9fQUxUUSBhY3Rpb24gcGFy YW1ldGVyczoKIAkJCSAqICAgcGVyZm9ybSBzb21lIGFjdGlvbiBhbmQgc2V0IG1hdGNoID0g MTsKIAkJCSAqCi0JCQkgKiBPX0xJTUlUIGFuZCBPX0tFRVBfU1RBVEU6IHRoZXNlIG9wY29k ZXMgYXJlCi0JCQkgKiAgIG5vdCByZWFsICdhY3Rpb25zJywgYW5kIGFyZSBzdG9yZWQgcmln aHQKLQkJCSAqICAgYmVmb3JlIHRoZSAnYWN0aW9uJyBwYXJ0IG9mIHRoZSBydWxlLgorCQkJ ICogT19MSU1JVCwgT19LRUVQX1NUQVRFIGFuZCBPX1NUQVRFX09OTFk6IHRoZXNlCisJCQkg KiAgIG9wY29kZXMgYXJlIG5vdCByZWFsICdhY3Rpb25zJywgYW5kIGFyZSBzdG9yZWQKKwkJ CSAqICAgcmlnaHQgYmVmb3JlIHRoZSAnYWN0aW9uJyBwYXJ0IG9mIHRoZSBydWxlLgogCQkJ ICogICBUaGVzZSBvcGNvZGVzIHRyeSB0byBpbnN0YWxsIGFuIGVudHJ5IGluIHRoZQogCQkJ ICogICBzdGF0ZSB0YWJsZXM7IGlmIHN1Y2Nlc3NmdWwsIHdlIGNvbnRpbnVlIHdpdGgKIAkJ CSAqICAgdGhlIG5leHQgb3Bjb2RlIChtYXRjaD0xOyBicmVhazspLCBvdGhlcndpc2UKQEAg LTIxMjYsOSArMjEyNiwyMCBAQAogCQkJICogICBmdXJ0aGVyIGluc3RhbmNlcyBvZiB0aGVz ZSBvcGNvZGVzIGJlY29tZSBOT1BzLgogCQkJICogICBUaGUganVtcCB0byB0aGUgbmV4dCBy dWxlIGlzIGRvbmUgYnkgc2V0dGluZwogCQkJICogICBsPTAsIGNtZGxlbj0wLgorCQkJICoK KwkJCSAqIE9fU1RBVEVfT05MWTogdGhpcyBvcGNvZGUgaXMgbm90IHJlYWwgJ2FjdGlvbicK KwkJCSAqICB0b28sIGFuZCBpcyBzdG9yZWQgcmlnaHQgYmVmb3JlIHRoZSAnYWN0aW9uJwor CQkJICogIHBhcnQgb2YgdGhlIHJ1bGUsIHJpZ2h0IGFmdGVyIE9fS0VFUF9TVEFURQorCQkJ ICogIG9wY29kZS4gSXQgY2F1c2VzIG1hdGNoIGZhaWx1cmUgc28gcmVhbAorCQkJICogICdh Y3Rpb24nIGNvdWxkIGJlIGV4ZWN1dGVkIG9ubHkgaWYgcnVsZQorCQkJICogIGlzIGNoZWNr ZWQgdmlhIGR5bmFtaWMgcnVsZSBmcm9tIHN0YXRlCisJCQkgKiAgdGFibGUsIGFzIGluIHN1 Y2ggY2FzZSBleGVjdXRpb24gc3RhcnRzCisJCQkgKiAgZnJvbSB0cnVlICdhY3Rpb24nIG9w Y29kZSBkaXJlY3RseS4KKwkJCSAqICAgCiAJCQkgKi8KIAkJCWNhc2UgT19MSU1JVDoKIAkJ CWNhc2UgT19LRUVQX1NUQVRFOgorCQkJY2FzZSBPX1NUQVRFX09OTFk6CiAJCQkJaWYgKGlw ZndfaW5zdGFsbF9zdGF0ZShjaGFpbiwgZiwKIAkJCQkgICAgKGlwZndfaW5zbl9saW1pdCAq KWNtZCwgYXJncywgdGFibGVhcmcpKSB7CiAJCQkJCS8qIGVycm9yIG9yIGxpbWl0IHZpb2xh dGlvbiAqLwpAQCAtMjEzNiw3ICsyMTQ3LDExIEBACiAJCQkJCWwgPSAwOwkvKiBleGl0IGlu bmVyIGxvb3AgKi8KIAkJCQkJZG9uZSA9IDE7IC8qIGV4aXQgb3V0ZXIgbG9vcCAqLwogCQkJ CX0KLQkJCQltYXRjaCA9IDE7CisJCQkJaWYgKGNtZC0+b3Bjb2RlID09IE9fU1RBVEVfT05M WSkgeworCQkJCQlsID0gMDsJLyogZXhpdCBpbm5lciBsb29wICovCisJCQkJCW1hdGNoID0g MDsKKwkJCQl9IGVsc2UKKwkJCQkJbWF0Y2ggPSAxOwogCQkJCWJyZWFrOwogCiAJCQljYXNl IE9fUFJPQkVfU1RBVEU6CkBAIC0yMTg4LDYgKzIyMDMsNyBAQAogCQkJCWJyZWFrOwogCiAJ CQljYXNlIE9fQUNDRVBUOgorCiAJCQkJcmV0dmFsID0gMDsJLyogYWNjZXB0ICovCiAJCQkJ bCA9IDA7CQkvKiBleGl0IGlubmVyIGxvb3AgKi8KIAkJCQlkb25lID0gMTsJLyogZXhpdCBv dXRlciBsb29wICovCkBAIC0yNTM3LDcgKzI1NTMsNyBAQAogCQkJCWRvbmUgPSAxOwkvKiBl eGl0IG91dGVyIGxvb3AgKi8KIAkJCQlicmVhazsKIAkJCX0KLQorCQkJCiAJCQlkZWZhdWx0 OgogCQkJCXBhbmljKCItLSB1bmtub3duIG9wY29kZSAlZFxuIiwgY21kLT5vcGNvZGUpOwog CQkJfSAvKiBlbmQgb2Ygc3dpdGNoKCkgb24gb3Bjb2RlcyAqLwpJbmRleDogc3lzL25ldHBm aWwvaXBmdy9pcF9md19keW5hbWljLmMKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc3lzL25ldHBmaWwv aXBmdy9pcF9md19keW5hbWljLmMJKHJldmlzaW9uIDI3ODE1MSkKKysrIHN5cy9uZXRwZmls L2lwZncvaXBfZndfZHluYW1pYy5jCSh3b3JraW5nIGNvcHkpCkBAIC03MDgsNiArNzA4LDcg QEAKIAogCXN3aXRjaCAoY21kLT5vLm9wY29kZSkgewogCWNhc2UgT19LRUVQX1NUQVRFOgkv KiBiaWRpciBydWxlICovCisJY2FzZSBPX1NUQVRFX09OTFk6CiAJCXEgPSBhZGRfZHluX3J1 bGUoJmFyZ3MtPmZfaWQsIGksIE9fS0VFUF9TVEFURSwgcnVsZSk7CiAJCWJyZWFrOwogCkBA IC0xMzU3LDYgKzEzNTgsNyBAQAogCQlzd2l0Y2ggKGNtZC0+b3Bjb2RlKSB7CiAJCWNhc2Ug T19MSU1JVDoKIAkJY2FzZSBPX0tFRVBfU1RBVEU6CisJCWNhc2UgT19TVEFURV9PTkxZOgog CQljYXNlIE9fUFJPQkVfU1RBVEU6CiAJCWNhc2UgT19DSEVDS19TVEFURToKIAkJCXJldHVy biAoMSk7CkluZGV4OiBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3NvY2tvcHQuYwo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09Ci0tLSBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3NvY2tvcHQuYwkocmV2aXNpb24g Mjc4MTUxKQorKysgc3lzL25ldHBmaWwvaXBmdy9pcF9md19zb2Nrb3B0LmMJKHdvcmtpbmcg Y29weSkKQEAgLTE0MzMsNiArMTQzMyw3IEBACiAJCXN3aXRjaCAoY21kLT5vcGNvZGUpIHsK IAkJY2FzZSBPX1BST0JFX1NUQVRFOgogCQljYXNlIE9fS0VFUF9TVEFURToKKwkJY2FzZSBP X1NUQVRFX09OTFk6CiAJCWNhc2UgT19QUk9UTzoKIAkJY2FzZSBPX0lQX1NSQ19NRToKIAkJ Y2FzZSBPX0lQX0RTVF9NRToK --------------050501000709010809070907 Content-Type: application/octet-stream; name="ipfw-state-only-v2.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-only-v2.diff.sig" iQJ8BAABCgBmBQJU0P2bXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3Au ZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFFQUIwM0M1OEJGREM0 NzhGAAoJEOqwPFi/3EePIxsQAK5cLdzjilkT9lO7q0JT4KmF+TTnx5uLQVLwppIdt5S/CBte xamb5G96KiGfGw19PDOTOWfe73FzOBVw/8G8ETyIig4TqbxfXDpRgkp38XcRKRsOdNm7C6Pt 99fo6FfaTeulRuYLKcbEqvXYF1JipADGogufPl8HkwImTy1iSG9C5yf22wW4tct3H5nOTcK8 3I1GaVBVwwUVlpIxIua2esQrPGGsyqGlCzkwBOCa/pH6p4INtj6JPAV+LRLbGRrb1tQuduBK pkjxoSSL+es1n8s1q+u7HiqNtDrMyb4YCB/vwAczt9qPT4XnUaPesjSmh9A7gNfAFhmifgb+ 0msVg2XmBwxYNhEppPI5PizDiQ/rQMA2P21zOVyvknhYSt8p9EayuKrFSv1hNW4gfprgmkY4 w/RDX0fG2K9C29BdHLSMCIG7lq+DwTttFhqFY6cSby7zfCgPjd77mJyNaFpoNOnVZEV/KPuO L1i+n+6zjaic7OZ8YXyV4XoQQx9pRe6wRvY2olRTs941QvbBTQAKjzdjq874cEOOXD5dTeOd 7vA55OaxI+y9wn3GNh2aAj3r4LwOy98MlW2q1rPS7PXdT4YACFa8bV6+gWYibqAfZBEDZsdm 521pgS1sRTIGvzENddLM01l9KQlLbSdofXHdy057yuQAgxv4m2fvecjlUsWd --------------050501000709010809070907-- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 05:06:59 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A04199CE; Wed, 4 Feb 2015 05:06:59 +0000 (UTC) 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 714D98CD; Wed, 4 Feb 2015 05:06:59 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t1456lxp041659 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Feb 2015 21:06:49 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1A8E1.8010100@freebsd.org> Date: Wed, 04 Feb 2015 13:06:41 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <54D06E5C.3090701@freebsd.org> <54D0951F.2000304@FreeBSD.org> In-Reply-To: <54D0951F.2000304@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.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:06:59 -0000 On 2/3/15 5:30 PM, Lev Serebryakov wrote: > >> looking at my own rules I don't seem to have a problem.. > You have "check-state" only once, on entrance, before all NATs, so > it could work only for packets which don't need NAT. And looks like > (correct me if I'm wrong) you don't try to track states of connections > passed through NAT. yes, because NAT is a stateful filter so it's a duplication > - -- > // Lev Serebryakov AKA Black Lion > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 05:13:13 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7FE3DB03 for ; Wed, 4 Feb 2015 05:13:13 +0000 (UTC) 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 48ED399D for ; Wed, 4 Feb 2015 05:13:12 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t145D967041702 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 3 Feb 2015 21:13:11 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1AA60.4030907@freebsd.org> Date: Wed, 04 Feb 2015 13:13:04 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> In-Reply-To: <54D0A1AA.4080402@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.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:13:13 -0000 On 2/3/15 6:23 PM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 03.02.2015 13:04, Ian Smith wrote: > >>> Now to make stateful firewall with NAT you need to make some not >>> very "readable" tricks to record state ("allow") of outbound >>> connection before NAT, but pass packet to NAT after that. I know >>> two: >>> >>> (a) skipto-nat-allow pattern from many HOWOTOs >> Lev, can you provide references for these HOWTOs you refer to? >> >> I have a suspicion that some of them should be taken out and shot. > google for "FreeBSD ipfw nat stateful" :) There are lot of them. Not > real HOWTOs, but blog posts & alike. > > BTW, without new mechanism it is really hard to do such firewall, as > we need action (nat) after "allow keep-state". It could be done with > this ugly skip-to or with "allow keep-state" in INCOMING section of > firewall, what is not much better, as I prefer to decide let packet > out or not in OUTCOMING part of firewall and with "allow keep-state" > in incoming path it flood state table with unused states. > > Another problem, that "keep-state" acts as "check-state" too, so you > could not have ANOTHER "keep-state" before NAT in outgoing part or you > miss nat completely (sate is created in outgoing path, and then > checked before nat in outgoing path with "keep-state", grrrrr, ugly!). yes I think "keep-state" should be deprecated and replaced or supplemented by 'save_state' that does NOT do an implicit 'check-state'.. I don't know whose idea that was but it's just wrong. (if the state exists, maybe just replace it..) > > > - -- > // Lev Serebryakov AKA Black Lion > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQJ8BAEBCgBmBQJU0KGqXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF > QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePYvYQALeGCF9EuZKP3jLDaRwad+TO > IhYq5I3xPPqU3eNEdQ6OqdFonVQ4mDB+UipZzspC/U5drf1qo2LkOF8oBNDlVDW4 > 2I+bgYStptIkpSoBOe5AGRYwO3jfec77GvXhR8cMeQZK2Z9NIazn5ZtFkdQyiiDU > +b7pxBQ0SbbMUT3hubl4H+v93dMGfjnzrFg1aSY4/uYnmilb8plWN1o4BshZVMSz > z1lrFSaorj4RNYxnpM6f6YtDDYx4TahA7+OILl/BvzmNoztWb5hKNX+1TGLZPcch > QE19iix+8O75yuVEMim6FxZ7u6sRk+4PpL/WzCLC2PpPxP/AyiFRh4zw7Q34HDNm > xPe4Nfzt5vDj0/2HYMY0q0UeSfVY/U0iB3TWmV/3HFObaLeibCgHqOFGmtCpHw5/ > EXJX36mpffO1wI6ImPAvQ9C/wE6/JdoL8R3EPrsN3hdNmoVNIrnDuaeAwiQM6Ljm > 4CHzsqlYYzyjzgyMmmJahaZ3Lrr0IjnVixC3/z46SfpPipaua8Pr+oZozC4WFmnn > 4IhsXH+XK7fTbKQaZML6o9j6Bm0hs9g6mt+VSWCYWGCHh/V3DzTuH2BECUeC8lsD > 9pwHv4x4vPbh7d/kBwAl75mOe3etb8nD/+i+x0oqbPn0T73DgdGgYPnIKqElOi4Y > Ws6uw/Euno3YnSSds5Eb > =FJZe > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://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 Feb 4 05:29:36 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BED7BC3B; Wed, 4 Feb 2015 05:29:36 +0000 (UTC) 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 8E634A97; Wed, 4 Feb 2015 05:29:36 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t145TW3e041754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Feb 2015 21:29:34 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1AE36.8090504@freebsd.org> Date: Wed, 04 Feb 2015 13:29:26 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] New "keep-state-only" option (version 2) References: <54D0F39B.4070707@FreeBSD.org> <54D0FD9B.5000108@FreeBSD.org> In-Reply-To: <54D0FD9B.5000108@FreeBSD.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: melifaro@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:29:36 -0000 On 2/4/15 12:55 AM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 03.02.2015 19:13, Lev Serebryakov wrote: > >> Ok, "allow-state"/"deny-state" was very limited idea. Here is more >> universal mechanism: new "keep-state-only" (aliased as >> "record-only") option, which works exactly as "keep-state" BUT >> cancel match of rule after state creation. It allows to write >> stateful + nat firewall as easy as: > To work as expected, "keep-state-only" should not imply "check-state" > in opposite to "keep-state". agreed.. I hate the implied check-state.. man page must be very explicit about this.. From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 05:33:02 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BEC8ED1A; Wed, 4 Feb 2015 05:33:02 +0000 (UTC) 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 88187B43; Wed, 4 Feb 2015 05:33:02 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t145WvOP041772 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Feb 2015 21:33:00 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1AF04.8050106@freebsd.org> Date: Wed, 04 Feb 2015 13:32:52 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] New "keep-state-only" option References: <54D0F39B.4070707@FreeBSD.org> In-Reply-To: <54D0F39B.4070707@FreeBSD.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: melifaro@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:33:03 -0000 On 2/4/15 12:13 AM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > > Ok, "allow-state"/"deny-state" was very limited idea. > Here is more universal mechanism: new "keep-state-only" (aliased as > "record-only") option, which works exactly as "keep-state" BUT cancel > match of rule after state creation. It allows to write stateful + nat > firewall as easy as: > > nat 1 config if outIface > > 1000 skipto 2000 in > skipto 3000 out > deny all from any to any // Safeguard > 2000 skipto 4000 recv inIface > skipto 6000 recv outIface > deny all from any to any // Safeguard > 3000 skipto 5000 xmit inIface > skipto 7000 xmit outIface > deny all from any to any // Safeguard > 4000 // For sake of simplicity! > // Real firewall will have some checks about local network here > allow all from any to any > deny all from any to any // Safeguard > 5000 // For sake of simplicity! > // Real firewall will have some checks about local network here > allow all from any to any > deny all from any to any // Safeguard > 6000 deny all not dst-ip $EXT_IP > nat 1 all from any to any > // All enabled with "keep-state-only" at block 7000 before NAT > check-state all from any to any > // Here could be accept rules for our servers or servers in DMZ > // Disable everything else > deny all from any to any > 7000 // Here goes rules which could DISABLE outbound external traffic > // Create state for "check-state" at block 6000 and fallthrough > allow keep-state-only > allow src-ip $EXT_IP // Save NAT some work > nat 1 all from any to any > allow all from any to any > deny all from any to any // Safeguard > > And variants with multiple NATs and "nat global" becomes as easy as > this, too! No stupid "skipto", no "keep-state" at "incoming from local > network" parts of firewall, nothing! > > P.S. I HATE this "all any to any" part! can we get rid of it? (implied).. or just add "everything" also I am not sure about "keep-state-only".. how about 'set-state'? or record-state as I started with.. > > - -- > // Lev Serebryakov > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQJ8BAEBCgBmBQJU0POaXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF > QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePR+gP/1Oxi+h7pi0UlnqfrKyfHJRS > FUbrMNeR9NATnTwxIK1UxNT1kF3m7wiwnFlgwW7rwLtTviFB1wK/pfd38l2h4t/w > qUbtyK4PFMCq8I6wAJIB0qUl3C/mN1rwc+LSJJyFM07R52snoQs6FvkIYkCz0fOy > Cak1f/P+scc21IRhFvYJXMMDO/1Y1nkxZk/HdHbn1GELpTXuHugvL1T9hHl98sqO > HKlHnvtqAVlyZn9Sv3uC9nsyjFA2sdOCtb67UGnPDV3CIs4Jwj5CSst5jbz13qFG > aXF8ZSm0coPJMUjH1PSogZM9Xiq23yZ47V0mesBxQsHL24548jM/wKcsR3buDjP7 > NJ2rqo2OBCzTu6VCK2oIY5j9A6vq1mu8+/eBs5jF4C2k0xHiw53Okou7zOCA0gJ+ > z+VGZvD3la/+tFjacty7Ra7LLNA8kNCnRa0QML7LOJ1/99a4l3Z/uGFxy5zYnk7d > p27Y85CAhTJQjkYZSGAiFD5SE4XxRqtSJ9OL89w7vLxoHqW0rqwi+DVrr9uvXQZS > 8Z5G5iQARG4ygXuKsl6MlwChCXa3ucbOs41lorrug94cuVCwGg859zBZY3dpQsKz > XIhtVQS21wPLxXywzIc678ar4uKVWNiaRWg+k57O7375gAszvqujRuTEcfHRf/T+ > gHJJZt8Tc+en4bw8XItY > =wOAJ > -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 05:38:34 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7ED06DFF; Wed, 4 Feb 2015 05:38:34 +0000 (UTC) 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 4F128B68; Wed, 4 Feb 2015 05:38:34 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t145cT2b041805 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 3 Feb 2015 21:38:32 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1B050.2040706@freebsd.org> Date: Wed, 04 Feb 2015 13:38:24 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] New "keep-state-only" option References: <54D0F39B.4070707@FreeBSD.org> <54D1AF04.8050106@freebsd.org> In-Reply-To: <54D1AF04.8050106@freebsd.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: melifaro@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 05:38:34 -0000 On 2/4/15 1:32 PM, Julian Elischer wrote: > On 2/4/15 12:13 AM, Lev Serebryakov wrote: >> >> And variants with multiple NATs and "nat global" becomes as easy as >> this, too! No stupid "skipto", no "keep-state" at "incoming from local >> network" parts of firewall, nothing! >> >> P.S. I HATE this "all any to any" part! > can we get rid of it? (implied).. or just add "everything" > also I am not sure about "keep-state-only".. > how about 'set-state'? or record-state as I started with.. or record-session.. (state always annoyed me) > > From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 09:22:42 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 206C747B; Wed, 4 Feb 2015 09:22:42 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id D5B983DA; Wed, 4 Feb 2015 09:22:41 +0000 (UTC) Received: from [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f] (unknown [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 0952D5C002; Wed, 4 Feb 2015 12:22:24 +0300 (MSK) Message-ID: <54D1E4D4.10106@FreeBSD.org> Date: Wed, 04 Feb 2015 12:22:28 +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.4.0 MIME-Version: 1.0 To: Julian Elischer , freebsd-ipfw@freebsd.org Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> <54D1AA60.4030907@freebsd.org> In-Reply-To: <54D1AA60.4030907@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 09:22:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04.02.2015 08:13, Julian Elischer wrote: > yes I think "keep-state" should be deprecated and replaced or > supplemented by 'save_state' that does NOT do an implicit > 'check-state'.. I don't know whose idea that was but it's just > wrong. (if the state exists, maybe just replace it..) Update, not replace :) See my Version-3 patch for "record-state" :) - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0eTUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePoS0P/iCMeTo+fFA4iGwe/8FnlF+y 899fomt4tzOBppxg1r5/xx11OMB9DJ6VG1z8+61gzIg1jgxvAIBTBGz5oxIgyfv5 mtbEbfhsxsABYTASjwIQymxR1zvLCbyd7fWgDRhM8YJYEy/akWNzOwtbokrkK1Ww 3j2IODup3onYr5LhwoQZGPdtmIyH10rnEcs49IWUs1ZweWlJx7XRQOGBAepTQRx9 bh/D0owV1j9BBzyqd5n54aXiQpMKMIdOihmNOOUYhl0B3GksacWguV7Keabbv0Dh Nnk3g/GrBYJPdmF0JqkocjrGxSuWAwBXfdXg3SoG8l1dPqaDg8UNVXq7VthS7FKO 8jyoRXaptbcrTjgG0SHdfnSzbhpLj78/PdGi1VvJwrvjnK2MNb6dZ2PE3E88ScgM f7OIOef9GyLwgAPqn6TJeiC7Oddvq+vL1vEigqLMJscJ4ErwqX8RVidbkYdNmKCf HYSd9mSJgkAMUH7q2U5PCRY9Ay6BOkuGHEqvMHGFClqBWb81RTyT8ZR+BL+JeqRr QNilMWvUXJSGEcvMYijKiv2EVDB6by3sY2SK9KLa93H0jY1nR3XPpilpyLcHLzN9 5aVknqR2/TzFDS1BiSEg/wYipyqjgIyHTqqxj0Vd0pnZMSw3AqdrOSLz8mHJzXKp 3J8Y7Lw7fuM1N8Doq2Md =/M0i -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 09:24:47 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08C1C5F9; Wed, 4 Feb 2015 09:24:47 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 56CD73EE; Wed, 4 Feb 2015 09:24:46 +0000 (UTC) Received: from [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f] (unknown [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 2185A5C002; Wed, 4 Feb 2015 12:24:36 +0300 (MSK) Message-ID: <54D1E558.1010700@FreeBSD.org> Date: Wed, 04 Feb 2015 12:24:40 +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.4.0 MIME-Version: 1.0 To: freebsd-ipfw , freebsd-net Subject: [RFC][patch] New "keep-state-only" option (version 3) References: <54D0F39B.4070707@FreeBSD.org> <54D0FD9B.5000108@FreeBSD.org> In-Reply-To: <54D0FD9B.5000108@FreeBSD.org> Content-Type: multipart/mixed; boundary="------------020107060303090503050300" Cc: julian@freebsd.org, melifaro@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 09:24:47 -0000 This is a multi-part message in MIME format. --------------020107060303090503050300 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 03.02.2015 19:55, Lev Serebryakov wrote: >> Ok, "allow-state"/"deny-state" was very limited idea. Here is >> more universal mechanism: new "keep-state-only" (aliased as >> "record-only") option, which works exactly as "keep-state" BUT >> cancel match of rule after state creation. It allows to write >> stateful + nat firewall as easy as: > To work as expected, "keep-state-only" should not imply > "check-state" in opposite to "keep-state". Re-installation of state (with second, third, etc... packet of connection) should update TCP state of state (sorry!), or it will die in 10 seconds. This version seems to be final (apart from name of new option!). It works perfectly on my router with 2 uplink ISPs. - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0eVYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePOD0P/RwpwF9yMUjyAj/KZnphr/0Y aXHM040qIocIUqnxH7T/vwdhm2w3Zciry8hwXp9f+r2bTIe8+tTn8OwaJ0M/Wp1j QBPxW+rjw49hy3rf2eIQbgX7nTwdIZo7YDnT82Kqtje1mImTBR4qdFcSStJac4hE dJsbpzC6raHUuE8h5V5pWPV/m/OQebK3P5CZzBKKpVTMCX3nVsTnff9qf9L1A0Jd q4KYfOv+NJBaB8G6vJhDHjcqtzGfEJBmYL8kOAslYhlUuyYe+iAhyGFbcUBsXwk8 /dqBalUL2iewFaZppszYZ0rTpVOfA4fOV0ECbVmpcw36uocrC2iOEpBl0WRIy+TM HYIMkIeubF9IT24CwMwiriONpppl8MGynCmL9hyMgu+HiuvHZ/C/vYcVV9/DHFGB iKkNe9QjX34anP6qVvEvHHmuv26PO7eq7hkdK2PZNlA9dwwNHehN8xG3DxB9N8gG MPRGtM8yH/C/FXpqKmHoqj6shMGQCSfmZKPfJ0D49Rze8tSjo7kZaSmaELJAjmsc xLv5umEAg7gym54bMhv8As2lXHnyeDp3uJz6glM72cmtBM5/n8N7NLk6Xga+8eM3 cZ122dgOqzGpts9TqCGWmTRW+f2Y8hLukzIjOLdzlqLPfQmXVn9pOWmqo9OKHdvD we0uYcnte/iSltopkVuG =muco -----END PGP SIGNATURE----- --------------020107060303090503050300 Content-Type: text/plain; charset=windows-1251; name="ipfw-state-only-v3.diff" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-only-v3.diff" SW5kZXg6IHNiaW4vaXBmdy9pcGZ3LjgKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3L2lw ZncuOAkocmV2aXNpb24gMjc4MTUxKQorKysgc2Jpbi9pcGZ3L2lwZncuOAkod29ya2luZyBj b3B5KQpAQCAtMTY2LDcgKzE2Niw4IEBACiBkZXBlbmRpbmcgb24gaG93IHRoZSBrZXJuZWwg aXMgY29uZmlndXJlZC4KIC5QcAogSWYgdGhlIHJ1bGVzZXQgaW5jbHVkZXMgb25lIG9yIG1v cmUgcnVsZXMgd2l0aCB0aGUKLS5DbSBrZWVwLXN0YXRlCisuQ20ga2VlcC1zdGF0ZSAsCisu Q20ga2VlcC1zdGF0ZS1vbmx5CiBvcgogLkNtIGxpbWl0CiBvcHRpb24sCkBAIC01ODIsNyAr NTgzLDggQEAKIHBhY2tldCBkZWxpdmVyeS4KIC5QcAogTm90ZTogdGhpcyBjb25kaXRpb24g aXMgY2hlY2tlZCBiZWZvcmUgYW55IG90aGVyIGNvbmRpdGlvbiwgaW5jbHVkaW5nCi1vbmVz IHN1Y2ggYXMga2VlcC1zdGF0ZSBvciBjaGVjay1zdGF0ZSB3aGljaCBtaWdodCBoYXZlIHNp ZGUgZWZmZWN0cy4KK29uZXMgc3VjaCBhcyBrZWVwLXN0YXRlLCBrZWVwLXN0YXQtb25seSBv ciBjaGVjay1zdGF0ZSB3aGljaCBtaWdodCBoYXZlCitzaWRlIGVmZmVjdHMuCiAuSXQgQ20g bG9nIE9wIENtIGxvZ2Ftb3VudCBBciBudW1iZXIKIFBhY2tldHMgbWF0Y2hpbmcgYSBydWxl IHdpdGggdGhlCiAuQ20gbG9nCkBAIC0xNTgzLDYgKzE1ODUsMTggQEAKIC5YciBzeXNjdGwg OAogdmFyaWFibGVzKSwgYW5kIHRoZSBsaWZldGltZSBpcyByZWZyZXNoZWQgZXZlcnkgdGlt ZSBhIG1hdGNoaW5nCiBwYWNrZXQgaXMgZm91bmQuCisuSXQgQ20ga2VlcC1zdGF0ZS1vbmx5 IHwgcmVjb3JkLW9ubHkKK1Vwb24gYSBtYXRjaCwgdGhlIGZpcmV3YWxsIHdpbGwgY3JlYXRl IGEgZHluYW1pYyBydWxlIGFzIGlmCisuQ20ga2VlcC1zdGF0ZQord2FzIHNwZWNpZmllZCwg YnV0IGFmdGVyIHRoYXQgbWF0Y2ggaXMgY2FuY2VsbGVkIGFuZCB0aGUgc2VhcmNoCitjb250 aW51ZXMgd2l0aCB0aGUgbmV4dCBydWxlLgorT24gZHluYW1pYyBydWxlIG1hdGNoIGFjdGlv biwgc3BlY2lmaWVkIGluIHRoaXMgcnVsZSwKK3BlcmZvcm1lZCBhcyBpZiBydWxlIGNvbnRh aW5zCisuQ20ga2VlcC1zdGF0ZSAuCitUaGlzIG9wdGlvbiBkb2Vzbid0IGFjdCBhcworLkNt IGNoZWNrLXN0YXRlCitpbiBjb250cmFzdCB0bworLkNtIGtlZXAtc3RhdGUgLgogLkl0IENt IGxheWVyMgogTWF0Y2hlcyBvbmx5IGxheWVyMiBwYWNrZXRzLCBpLmUuLCB0aG9zZSBwYXNz ZWQgdG8KIC5ObQpJbmRleDogc2Jpbi9pcGZ3L2lwZncyLmMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0g c2Jpbi9pcGZ3L2lwZncyLmMJKHJldmlzaW9uIDI3ODE1MSkKKysrIHNiaW4vaXBmdy9pcGZ3 Mi5jCSh3b3JraW5nIGNvcHkpCkBAIC0yOTIsNiArMjkyLDggQEAKIAl7ICJpbiIsCQkJVE9L X0lOIH0sCiAJeyAibGltaXQiLAkJVE9LX0xJTUlUIH0sCiAJeyAia2VlcC1zdGF0ZSIsCQlU T0tfS0VFUFNUQVRFIH0sCisJeyAicmVjb3JkLXN0YXRlIiwJVE9LX1NUQVRFX09OTFkgfSwK Kwl7ICJrZWVwLXN0YXRlLW9ubHkiLAlUT0tfU1RBVEVfT05MWSB9LAogCXsgImJyaWRnZWQi LAkJVE9LX0xBWUVSMiB9LAogCXsgImxheWVyMiIsCQlUT0tfTEFZRVIyIH0sCiAJeyAib3V0 IiwJCVRPS19PVVQgfSwKQEAgLTE5OTMsNiArMTk5NSwxMCBAQAogCQkJCWJwcmludGYoYnAs ICIga2VlcC1zdGF0ZSIpOwogCQkJCWJyZWFrOwogCisJCQljYXNlIE9fU1RBVEVfT05MWToK KwkJCQlicHJpbnRmKGJwLCAiIGtlZXAtc3RhdGUtb25seSIpOworCQkJCWJyZWFrOworCiAJ CQljYXNlIE9fTElNSVQ6IHsKIAkJCQlzdHJ1Y3QgX3NfeCAqcCA9IGxpbWl0X21hc2tzOwog CQkJCWlwZndfaW5zbl9saW1pdCAqYyA9IChpcGZ3X2luc25fbGltaXQgKiljbWQ7CkBAIC00 MzM1LDE0ICs0MzQxLDE2IEBACiAJCQlicmVhazsKIAogCQljYXNlIFRPS19LRUVQU1RBVEU6 CisJCWNhc2UgVE9LX1NUQVRFX09OTFk6CiAJCQlpZiAob3Blbl9wYXIpCi0JCQkJZXJyeChF WF9VU0FHRSwgImtlZXAtc3RhdGUgY2Fubm90IGJlIHBhcnQgIgorCQkJCWVycngoRVhfVVNB R0UsICJrZWVwLXN0YXRlIG9yIGtlZXAtc3RhdGUtb25seSBjYW5ub3QgYmUgcGFydCAiCiAJ CQkJICAgICJvZiBhbiBvciBibG9jayIpOwogCQkJaWYgKGhhdmVfc3RhdGUpCiAJCQkJZXJy eChFWF9VU0FHRSwgIm9ubHkgb25lIG9mIGtlZXAtc3RhdGUgIgogCQkJCQkiYW5kIGxpbWl0 IGlzIGFsbG93ZWQiKTsKIAkJCWhhdmVfc3RhdGUgPSBjbWQ7Ci0JCQlmaWxsX2NtZChjbWQs IE9fS0VFUF9TVEFURSwgMCwgMCk7CisJCQlmaWxsX2NtZChjbWQsIGkgPT0gVE9LX0tFRVBT VEFURSA/CisJCQkJT19LRUVQX1NUQVRFIDogT19TVEFURV9PTkxZLCAwLCAwKTsKIAkJCWJy ZWFrOwogCiAJCWNhc2UgVE9LX0xJTUlUOiB7CkBAIC00NTgwLDEyICs0NTg4LDEzIEBACiAJ LyoKIAkgKiBnZW5lcmF0ZSBPX1BST0JFX1NUQVRFIGlmIG5lY2Vzc2FyeQogCSAqLwotCWlm IChoYXZlX3N0YXRlICYmIGhhdmVfc3RhdGUtPm9wY29kZSAhPSBPX0NIRUNLX1NUQVRFKSB7 CisJaWYgKGhhdmVfc3RhdGUgJiYgaGF2ZV9zdGF0ZS0+b3Bjb2RlICE9IE9fQ0hFQ0tfU1RB VEUgJiYKKwkgICAgaGF2ZV9zdGF0ZS0+b3Bjb2RlICE9IE9fU1RBVEVfT05MWSkgewogCQlm aWxsX2NtZChkc3QsIE9fUFJPQkVfU1RBVEUsIDAsIDApOwogCQlkc3QgPSBuZXh0X2NtZChk c3QsICZyYmxlbik7CiAJfQogCi0JLyogY29weSBhbGwgY29tbWFuZHMgYnV0IE9fTE9HLCBP X0tFRVBfU1RBVEUsIE9fTElNSVQsIE9fQUxUUSwgT19UQUcgKi8KKwkvKiBjb3B5IGFsbCBj b21tYW5kcyBidXQgT19MT0csIE9fS0VFUF9TVEFURSwgT19TVEFURV9PTkxZLCBPX0xJTUlU LCBPX0FMVFEsIE9fVEFHICovCiAJZm9yIChzcmMgPSAoaXBmd19pbnNuICopY21kYnVmOyBz cmMgIT0gY21kOyBzcmMgKz0gaSkgewogCQlpID0gRl9MRU4oc3JjKTsKIAkJQ0hFQ0tfUkJV RkxFTihpKTsKQEAgLTQ1OTMsNiArNDYwMiw3IEBACiAJCXN3aXRjaCAoc3JjLT5vcGNvZGUp IHsKIAkJY2FzZSBPX0xPRzoKIAkJY2FzZSBPX0tFRVBfU1RBVEU6CisJCWNhc2UgT19TVEFU RV9PTkxZOgogCQljYXNlIE9fTElNSVQ6CiAJCWNhc2UgT19BTFRROgogCQljYXNlIE9fVEFH OgpJbmRleDogc2Jpbi9pcGZ3L2lwZncyLmgKPT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQotLS0gc2Jpbi9pcGZ3 L2lwZncyLmgJKHJldmlzaW9uIDI3ODE1MSkKKysrIHNiaW4vaXBmdy9pcGZ3Mi5oCSh3b3Jr aW5nIGNvcHkpCkBAIC0yMjcsNiArMjI3LDcgQEAKIAlUT0tfTE9DSywKIAlUT0tfVU5MT0NL LAogCVRPS19WTElTVCwKKwlUT0tfU1RBVEVfT05MWSwKIH07CiAKIC8qCkluZGV4OiBzeXMv bmV0aW5ldC9pcF9mdy5oCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRpbmV0L2lwX2Z3LmgJ KHJldmlzaW9uIDI3ODE1MSkKKysrIHN5cy9uZXRpbmV0L2lwX2Z3LmgJKHdvcmtpbmcgY29w eSkKQEAgLTI1Miw2ICsyNTIsOCBAQAogCU9fRFNDUCwJCQkvKiAyIHUzMiA9IERTQ1AgbWFz ayAqLwogCU9fU0VURFNDUCwJCS8qIGFyZzE9RFNDUCB2YWx1ZSAqLwogCU9fSVBfRkxPV19M T09LVVAsCS8qIGFyZzE9dGFibGUgbnVtYmVyLCB1MzI9dmFsdWUJKi8KKwkKKwlPX1NUQVRF X09OTFksCQkvKiBub25lCQkJCSovCiAKIAlPX0xBU1RfT1BDT0RFCQkvKiBub3QgYW4gb3Bj b2RlIQkJKi8KIH07CkluZGV4OiBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3Mi5jCj09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0KLS0tIHN5cy9uZXRwZmlsL2lwZncvaXBfZncyLmMJKHJldmlzaW9uIDI3ODE1MSkK KysrIHN5cy9uZXRwZmlsL2lwZncvaXBfZncyLmMJKHdvcmtpbmcgY29weSkKQEAgLTIxMDcs OSArMjEwNyw5IEBACiAJCQkgKiBPX1RBRywgT19MT0cgYW5kIE9fQUxUUSBhY3Rpb24gcGFy YW1ldGVyczoKIAkJCSAqICAgcGVyZm9ybSBzb21lIGFjdGlvbiBhbmQgc2V0IG1hdGNoID0g MTsKIAkJCSAqCi0JCQkgKiBPX0xJTUlUIGFuZCBPX0tFRVBfU1RBVEU6IHRoZXNlIG9wY29k ZXMgYXJlCi0JCQkgKiAgIG5vdCByZWFsICdhY3Rpb25zJywgYW5kIGFyZSBzdG9yZWQgcmln aHQKLQkJCSAqICAgYmVmb3JlIHRoZSAnYWN0aW9uJyBwYXJ0IG9mIHRoZSBydWxlLgorCQkJ ICogT19MSU1JVCwgT19LRUVQX1NUQVRFIGFuZCBPX1NUQVRFX09OTFk6IHRoZXNlCisJCQkg KiAgIG9wY29kZXMgYXJlIG5vdCByZWFsICdhY3Rpb25zJywgYW5kIGFyZSBzdG9yZWQKKwkJ CSAqICAgcmlnaHQgYmVmb3JlIHRoZSAnYWN0aW9uJyBwYXJ0IG9mIHRoZSBydWxlLgogCQkJ ICogICBUaGVzZSBvcGNvZGVzIHRyeSB0byBpbnN0YWxsIGFuIGVudHJ5IGluIHRoZQogCQkJ ICogICBzdGF0ZSB0YWJsZXM7IGlmIHN1Y2Nlc3NmdWwsIHdlIGNvbnRpbnVlIHdpdGgKIAkJ CSAqICAgdGhlIG5leHQgb3Bjb2RlIChtYXRjaD0xOyBicmVhazspLCBvdGhlcndpc2UKQEAg LTIxMjYsMTcgKzIxMjYsMzMgQEAKIAkJCSAqICAgZnVydGhlciBpbnN0YW5jZXMgb2YgdGhl c2Ugb3Bjb2RlcyBiZWNvbWUgTk9Qcy4KIAkJCSAqICAgVGhlIGp1bXAgdG8gdGhlIG5leHQg cnVsZSBpcyBkb25lIGJ5IHNldHRpbmcKIAkJCSAqICAgbD0wLCBjbWRsZW49MC4KKwkJCSAq CisJCQkgKiBPX1NUQVRFX09OTFk6IHRoaXMgb3Bjb2RlIGlzIG5vdCByZWFsICdhY3Rpb24n CisJCQkgKiAgdG9vLCBhbmQgaXMgc3RvcmVkIHJpZ2h0IGJlZm9yZSB0aGUgJ2FjdGlvbicK KwkJCSAqICBwYXJ0IG9mIHRoZSBydWxlLCByaWdodCBhZnRlciBPX0tFRVBfU1RBVEUKKwkJ CSAqICBvcGNvZGUuIEl0IGNhdXNlcyBtYXRjaCBmYWlsdXJlIHNvIHJlYWwKKwkJCSAqICAn YWN0aW9uJyBjb3VsZCBiZSBleGVjdXRlZCBvbmx5IGlmIHJ1bGUKKwkJCSAqICBpcyBjaGVj a2VkIHZpYSBkeW5hbWljIHJ1bGUgZnJvbSBzdGF0ZQorCQkJICogIHRhYmxlLCBhcyBpbiBz dWNoIGNhc2UgZXhlY3V0aW9uIHN0YXJ0cworCQkJICogIGZyb20gdHJ1ZSAnYWN0aW9uJyBv cGNvZGUgZGlyZWN0bHkuCisJCQkgKiAgIAogCQkJICovCiAJCQljYXNlIE9fTElNSVQ6CiAJ CQljYXNlIE9fS0VFUF9TVEFURToKLQkJCQlpZiAoaXBmd19pbnN0YWxsX3N0YXRlKGNoYWlu LCBmLAotCQkJCSAgICAoaXBmd19pbnNuX2xpbWl0ICopY21kLCBhcmdzLCB0YWJsZWFyZykp IHsKKwkJCWNhc2UgT19TVEFURV9PTkxZOgorCQkJCWlmIChpcGZ3X2luc3RhbGxfb3JfdXBk YXRlX3N0YXRlKGNoYWluLCBmLAorCQkJCSAgICAoaXBmd19pbnNuX2xpbWl0ICopY21kLCBh cmdzLCB0YWJsZWFyZywKKwkJCQkgICAgcHJvdG8gPT0gSVBQUk9UT19UQ1AgPyBUQ1AodWxw KSA6IE5VTEwpKSB7CiAJCQkJCS8qIGVycm9yIG9yIGxpbWl0IHZpb2xhdGlvbiAqLwogCQkJ CQlyZXR2YWwgPSBJUF9GV19ERU5ZOwogCQkJCQlsID0gMDsJLyogZXhpdCBpbm5lciBsb29w ICovCiAJCQkJCWRvbmUgPSAxOyAvKiBleGl0IG91dGVyIGxvb3AgKi8KIAkJCQl9Ci0JCQkJ bWF0Y2ggPSAxOworCQkJCWlmIChjbWQtPm9wY29kZSA9PSBPX1NUQVRFX09OTFkpIHsKKwkJ CQkJbCA9IDA7CS8qIGV4aXQgaW5uZXIgbG9vcCAqLworCQkJCQltYXRjaCA9IDA7CisJCQkJ fSBlbHNlCisJCQkJCW1hdGNoID0gMTsKIAkJCQlicmVhazsKIAogCQkJY2FzZSBPX1BST0JF X1NUQVRFOgpAQCAtMjE4OCw2ICsyMjA0LDcgQEAKIAkJCQlicmVhazsKIAogCQkJY2FzZSBP X0FDQ0VQVDoKKwogCQkJCXJldHZhbCA9IDA7CS8qIGFjY2VwdCAqLwogCQkJCWwgPSAwOwkJ LyogZXhpdCBpbm5lciBsb29wICovCiAJCQkJZG9uZSA9IDE7CS8qIGV4aXQgb3V0ZXIgbG9v cCAqLwpAQCAtMjUzNyw3ICsyNTU0LDcgQEAKIAkJCQlkb25lID0gMTsJLyogZXhpdCBvdXRl ciBsb29wICovCiAJCQkJYnJlYWs7CiAJCQl9Ci0KKwkJCQogCQkJZGVmYXVsdDoKIAkJCQlw YW5pYygiLS0gdW5rbm93biBvcGNvZGUgJWRcbiIsIGNtZC0+b3Bjb2RlKTsKIAkJCX0gLyog ZW5kIG9mIHN3aXRjaCgpIG9uIG9wY29kZXMgKi8KSW5kZXg6IHN5cy9uZXRwZmlsL2lwZncv aXBfZndfZHluYW1pYy5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRwZmlsL2lwZncvaXBf ZndfZHluYW1pYy5jCShyZXZpc2lvbiAyNzgxNTEpCisrKyBzeXMvbmV0cGZpbC9pcGZ3L2lw X2Z3X2R5bmFtaWMuYwkod29ya2luZyBjb3B5KQpAQCAtNjY5LDEzICs2NjksMTUgQEAKIAog LyoqCiAgKiBJbnN0YWxsIGR5bmFtaWMgc3RhdGUgZm9yIHJ1bGUgdHlwZSBjbWQtPm8ub3Bj b2RlCisgKiBJZiBydWxlIGV4aXN0cywgdXBkYXRlIGl0IHN0YXRlLgogICoKICAqIFJldHVy bnMgMSAoZmFpbHVyZSkgaWYgc3RhdGUgaXMgbm90IGluc3RhbGxlZCBiZWNhdXNlIG9mIGVy cm9ycyBvciBiZWNhdXNlCiAgKiBzZXNzaW9uIGxpbWl0YXRpb25zIGFyZSBlbmZvcmNlZC4K ICAqLwogaW50Ci1pcGZ3X2luc3RhbGxfc3RhdGUoc3RydWN0IGlwX2Z3X2NoYWluICpjaGFp biwgc3RydWN0IGlwX2Z3ICpydWxlLAotICAgIGlwZndfaW5zbl9saW1pdCAqY21kLCBzdHJ1 Y3QgaXBfZndfYXJncyAqYXJncywgdWludDMyX3QgdGFibGVhcmcpCitpcGZ3X2luc3RhbGxf b3JfdXBkYXRlX3N0YXRlKHN0cnVjdCBpcF9md19jaGFpbiAqY2hhaW4sIHN0cnVjdCBpcF9m dyAqcnVsZSwKKyAgICBpcGZ3X2luc25fbGltaXQgKmNtZCwgc3RydWN0IGlwX2Z3X2FyZ3Mg KmFyZ3MsIHVpbnQzMl90IHRhYmxlYXJnLAorICAgIHN0cnVjdCB0Y3BoZHIgKnRjcCkKIHsK IAlpcGZ3X2R5bl9ydWxlICpxOwogCWludCBpOwpAQCAtNjg2LDcgKzY4OCw3IEBACiAKIAlJ UEZXX0JVQ0tfTE9DSyhpKTsKIAotCXEgPSBsb29rdXBfZHluX3J1bGVfbG9ja2VkKCZhcmdz LT5mX2lkLCBpLCBOVUxMLCBOVUxMKTsKKwlxID0gbG9va3VwX2R5bl9ydWxlX2xvY2tlZCgm YXJncy0+Zl9pZCwgaSwgTlVMTCwgdGNwKTsKIAogCWlmIChxICE9IE5VTEwpIHsJLyogc2hv dWxkIG5ldmVyIG9jY3VyICovCiAJCURFQigKQEAgLTcwOCw2ICs3MTAsNyBAQAogCiAJc3dp dGNoIChjbWQtPm8ub3Bjb2RlKSB7CiAJY2FzZSBPX0tFRVBfU1RBVEU6CS8qIGJpZGlyIHJ1 bGUgKi8KKwljYXNlIE9fU1RBVEVfT05MWToKIAkJcSA9IGFkZF9keW5fcnVsZSgmYXJncy0+ Zl9pZCwgaSwgT19LRUVQX1NUQVRFLCBydWxlKTsKIAkJYnJlYWs7CiAKQEAgLTEzNTcsNiAr MTM2MCw3IEBACiAJCXN3aXRjaCAoY21kLT5vcGNvZGUpIHsKIAkJY2FzZSBPX0xJTUlUOgog CQljYXNlIE9fS0VFUF9TVEFURToKKwkJY2FzZSBPX1NUQVRFX09OTFk6CiAJCWNhc2UgT19Q Uk9CRV9TVEFURToKIAkJY2FzZSBPX0NIRUNLX1NUQVRFOgogCQkJcmV0dXJuICgxKTsKSW5k ZXg6IHN5cy9uZXRwZmlsL2lwZncvaXBfZndfcHJpdmF0ZS5oCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0t IHN5cy9uZXRwZmlsL2lwZncvaXBfZndfcHJpdmF0ZS5oCShyZXZpc2lvbiAyNzgxNTEpCisr KyBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3ByaXZhdGUuaAkod29ya2luZyBjb3B5KQpAQCAt MTgzLDggKzE4Myw5IEBACiBzdHJ1Y3QgdGNwaGRyOwogc3RydWN0IG1idWYgKmlwZndfc2Vu ZF9wa3Qoc3RydWN0IG1idWYgKiwgc3RydWN0IGlwZndfZmxvd19pZCAqLAogICAgIHVfaW50 MzJfdCwgdV9pbnQzMl90LCBpbnQpOwotaW50IGlwZndfaW5zdGFsbF9zdGF0ZShzdHJ1Y3Qg aXBfZndfY2hhaW4gKmNoYWluLCBzdHJ1Y3QgaXBfZncgKnJ1bGUsCi0gICAgaXBmd19pbnNu X2xpbWl0ICpjbWQsIHN0cnVjdCBpcF9md19hcmdzICphcmdzLCB1aW50MzJfdCB0YWJsZWFy Zyk7CitpbnQgaXBmd19pbnN0YWxsX29yX3VwZGF0ZV9zdGF0ZShzdHJ1Y3QgaXBfZndfY2hh aW4gKmNoYWluLCBzdHJ1Y3QgaXBfZncgKnJ1bGUsCisgICAgaXBmd19pbnNuX2xpbWl0ICpj bWQsIHN0cnVjdCBpcF9md19hcmdzICphcmdzLCB1aW50MzJfdCB0YWJsZWFyZywKKyAgICBz dHJ1Y3QgdGNwaGRyICp0Y3ApOwogaXBmd19keW5fcnVsZSAqaXBmd19sb29rdXBfZHluX3J1 bGUoc3RydWN0IGlwZndfZmxvd19pZCAqcGt0LAogCWludCAqbWF0Y2hfZGlyZWN0aW9uLCBz dHJ1Y3QgdGNwaGRyICp0Y3ApOwogdm9pZCBpcGZ3X3JlbW92ZV9keW5fY2hpbGRyZW4oc3Ry dWN0IGlwX2Z3ICpydWxlKTsKSW5kZXg6IHN5cy9uZXRwZmlsL2lwZncvaXBfZndfc29ja29w dC5jCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT0KLS0tIHN5cy9uZXRwZmlsL2lwZncvaXBfZndfc29ja29wdC5j CShyZXZpc2lvbiAyNzgxNTEpCisrKyBzeXMvbmV0cGZpbC9pcGZ3L2lwX2Z3X3NvY2tvcHQu Ywkod29ya2luZyBjb3B5KQpAQCAtMTQzMyw2ICsxNDMzLDcgQEAKIAkJc3dpdGNoIChjbWQt Pm9wY29kZSkgewogCQljYXNlIE9fUFJPQkVfU1RBVEU6CiAJCWNhc2UgT19LRUVQX1NUQVRF OgorCQljYXNlIE9fU1RBVEVfT05MWToKIAkJY2FzZSBPX1BST1RPOgogCQljYXNlIE9fSVBf U1JDX01FOgogCQljYXNlIE9fSVBfRFNUX01FOgo= --------------020107060303090503050300 Content-Type: application/octet-stream; name="ipfw-state-only-v3.diff.sig" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="ipfw-state-only-v3.diff.sig" iQJ8BAABCgBmBQJU0eVYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9wZW5wZ3Au ZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFFQUIwM0M1OEJGREM0 NzhGAAoJEOqwPFi/3EeP2YgQAKCEWSHEP1mmS5S8BHDTV1GsImxOJ64Bj6Zr+tGG2WpRiMIJ /0gr0AcMa7QxxZAQ2U5gYNf9g8/BFAmpNOI54oJKlwL0BuJYLbaL6QM4Si5Sy8mzVIVGdm1a K/PbZ+G7Meg8eHyDv5+VjTErDWN4TH71hgPRZgOIJvZaB5JIcYDUZdYsd6k+Y6trh4QbPxrQ A2neRTyVKtQUuAoTyvpuDbu0eTGVCi/8NWQWzlr9h9jvUO/dGE5vuiDD3f9SBHnEGTaGxk48 Co2E/Xbb2W6n+T8niFKFAq8jdWVCrQuAvZiKIWgPUdha3PKLi32r1gRH9zRK7kPO07Z4JE5F srEJRSVqP0zxeQ/9QkR3+OQ4nyfsjip/jGJk4/7VMsh7L0zcSK5dtrH0G92FkcpVQyPcQx/p c1/d+6n76W35gcjzN+hkY+1vNweaD8in2qNrLwVnlI7DB2q/2l5Ujv9pUOlJY3UwPbSYJjnd pnAmWv/eIL4SawSm/vq/J/3ontgzBQx+hVMNnKy/S6yyh7T7t8uS3zO0HnlMdDLkIE0QojWz S7Cr8fjPiRHbkOf5Df254P7RK5RiuB1Q9YLxF8DQ18rah6fospj5xWOFRiWrVcmOcvNUI9Lh FQjAUYZXba+aAja+qryfoT3IQE6t2OAkPz0jhg0XiH5r5soQsOBa1L3S5H27 --------------020107060303090503050300-- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 10:08:36 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8B412E81; Wed, 4 Feb 2015 10:08:36 +0000 (UTC) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com [IPv6:2607:f8b0:400e:c03::231]) (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 580D3A5B; Wed, 4 Feb 2015 10:08:36 +0000 (UTC) Received: by mail-pa0-f49.google.com with SMTP id fa1so1659010pad.8; Wed, 04 Feb 2015 02:08:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Ls3x6uuXzu51t1mo8ymC5rDgGCaSm27DQYaUwMuc0qY=; b=yBQ+P94u7cgxtg7tS2NUR/t2ZaekS9joulKZkEdssGIocM3FMjQAbsNENFq2xbJa+4 jqN/JoPAKy+gPDU/z6b2HS+RG6wD9hJegJL+INNP/oMwLcbj00I/WvywmhocZMFS0PNs f/C9KjwWVRznDFMLhqJCmtZnyrSw44gXE0jl7uLEgCk1c+nsra74ZFzW6GJQZm/OY6iw +N+vfxisN2iJKmU2zht40NZVjbfYvjvx17MP3uvM/qzIXnYudOsfeWyGF1fOBfjp+6Mq dZSbCLXj8I0mx+KIpwbQgt7j45/0GO8IbRwu80gMq5tou3XUDVBJdYRJsTWCmU1HuDVD oUiQ== MIME-Version: 1.0 X-Received: by 10.68.197.72 with SMTP id is8mr14085918pbc.17.1423044515941; Wed, 04 Feb 2015 02:08:35 -0800 (PST) Received: by 10.70.45.228 with HTTP; Wed, 4 Feb 2015 02:08:35 -0800 (PST) In-Reply-To: <54D1E558.1010700@FreeBSD.org> References: <54D0F39B.4070707@FreeBSD.org> <54D0FD9B.5000108@FreeBSD.org> <54D1E558.1010700@FreeBSD.org> Date: Wed, 4 Feb 2015 18:08:35 +0800 Message-ID: Subject: Re: [RFC][patch] New "keep-state-only" option (version 3) From: bycn82 To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ipfw , "Alexander V. Chernikov" , Julian Elischer , freebsd-net X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 10:08:36 -0000 *Cool, But maybe not all people are following this topic, so can you please simplify it by answering below question in order to allow more people to know what is going on here.* *What kind of problem you are facing and how does your patch resolve it?* On 4 February 2015 at 17:24, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 03.02.2015 19:55, Lev Serebryakov wrote: > > >> Ok, "allow-state"/"deny-state" was very limited idea. Here is > >> more universal mechanism: new "keep-state-only" (aliased as > >> "record-only") option, which works exactly as "keep-state" BUT > >> cancel match of rule after state creation. It allows to write > >> stateful + nat firewall as easy as: > > To work as expected, "keep-state-only" should not imply > > "check-state" in opposite to "keep-state". > Re-installation of state (with second, third, etc... packet of > connection) should update TCP state of state (sorry!), or it will die > in 10 seconds. > This version seems to be final (apart from name of new option!). > It works perfectly on my router with 2 uplink ISPs. > > - -- > // Lev Serebryakov AKA Black Lion > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQJ8BAEBCgBmBQJU0eVYXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF > QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePOD0P/RwpwF9yMUjyAj/KZnphr/0Y > aXHM040qIocIUqnxH7T/vwdhm2w3Zciry8hwXp9f+r2bTIe8+tTn8OwaJ0M/Wp1j > QBPxW+rjw49hy3rf2eIQbgX7nTwdIZo7YDnT82Kqtje1mImTBR4qdFcSStJac4hE > dJsbpzC6raHUuE8h5V5pWPV/m/OQebK3P5CZzBKKpVTMCX3nVsTnff9qf9L1A0Jd > q4KYfOv+NJBaB8G6vJhDHjcqtzGfEJBmYL8kOAslYhlUuyYe+iAhyGFbcUBsXwk8 > /dqBalUL2iewFaZppszYZ0rTpVOfA4fOV0ECbVmpcw36uocrC2iOEpBl0WRIy+TM > HYIMkIeubF9IT24CwMwiriONpppl8MGynCmL9hyMgu+HiuvHZ/C/vYcVV9/DHFGB > iKkNe9QjX34anP6qVvEvHHmuv26PO7eq7hkdK2PZNlA9dwwNHehN8xG3DxB9N8gG > MPRGtM8yH/C/FXpqKmHoqj6shMGQCSfmZKPfJ0D49Rze8tSjo7kZaSmaELJAjmsc > xLv5umEAg7gym54bMhv8As2lXHnyeDp3uJz6glM72cmtBM5/n8N7NLk6Xga+8eM3 > cZ122dgOqzGpts9TqCGWmTRW+f2Y8hLukzIjOLdzlqLPfQmXVn9pOWmqo9OKHdvD > we0uYcnte/iSltopkVuG > =muco > -----END PGP SIGNATURE----- > > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://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 Feb 4 11:01:20 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EDE93DF6 for ; Wed, 4 Feb 2015 11:01:20 +0000 (UTC) Received: from nskntqsrv02p.mx.bigpond.com (nskntqsrv02p.mx.bigpond.com [61.9.168.234]) by mx1.freebsd.org (Postfix) with ESMTP id 88D9AD6 for ; Wed, 4 Feb 2015 11:01:19 +0000 (UTC) Received: from nskntcmgw05p ([61.9.169.165]) by nskntmtas03p.mx.bigpond.com with ESMTP id <20150204105253.IXBI7575.nskntmtas03p.mx.bigpond.com@nskntcmgw05p> for ; Wed, 4 Feb 2015 10:52:53 +0000 Received: from hermes.heuristicsystems.com.au ([203.41.22.114]) by nskntcmgw05p with BigPond Outbound id oAst1p00N2ThMyb01AstN9; Wed, 04 Feb 2015 10:52:53 +0000 X-Authority-Analysis: v=2.0 cv=W5W6pGqk c=1 sm=1 a=tBIanQelQkU72CJWnm+MWA==:17 a=XD52yEjQpfAA:10 a=N659UExz7-8A:10 a=GHIR_BbyAAAA:8 a=0HtSIViG9nkA:10 a=4H3hmQKDrdvAKWf0_aUA:9 a=pILNOxqGKmIA:10 a=tBIanQelQkU72CJWnm+MWA==:117 Received: from [10.0.5.3] (ewsw01.hs [10.0.5.3]) (authenticated bits=0) by hermes.heuristicsystems.com.au (8.14.5/8.13.6) with ESMTP id t146HC3H019822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for ; Wed, 4 Feb 2015 17:17:14 +1100 (EST) (envelope-from dewayne.geraghty@heuristicsystems.com.au) Message-ID: <54D1B962.4060700@heuristicsystems.com.au> Date: Wed, 04 Feb 2015 17:17:06 +1100 From: Dewayne Geraghty User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: Re: [RFC][patch] New "keep-state-only" option References: <54D0F39B.4070707@FreeBSD.org> <54D1AF04.8050106@freebsd.org> <54D1B050.2040706@freebsd.org> In-Reply-To: <54D1B050.2040706@freebsd.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 11:01:21 -0000 On 4/02/2015 4:38 PM, Julian Elischer wrote: > On 2/4/15 1:32 PM, Julian Elischer wrote: >> On 2/4/15 12:13 AM, Lev Serebryakov wrote: >>> >>> And variants with multiple NATs and "nat global" becomes as easy as >>> this, too! No stupid "skipto", no "keep-state" at "incoming from local >>> network" parts of firewall, nothing! >>> >>> P.S. I HATE this "all any to any" part! >> can we get rid of it? (implied).. or just add "everything" >> also I am not sure about "keep-state-only".. >> how about 'set-state'? or record-state as I started with.. > or record-session.. (state always annoyed me) > >> >> record-state seems more intuitive, while record-session suggests a wider scope involving session negotiation. Regards, Dewayne. From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 11:04:17 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3D3DCF; Wed, 4 Feb 2015 11:04:17 +0000 (UTC) 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 9448C103; Wed, 4 Feb 2015 11:04:17 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t14B4BFQ043083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 Feb 2015 03:04:14 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1FCA5.5030408@freebsd.org> Date: Wed, 04 Feb 2015 19:04:05 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw , freebsd-net Subject: Re: [RFC][patch] New "keep-state-only" option (version 3) References: <54D0F39B.4070707@FreeBSD.org> <54D0FD9B.5000108@FreeBSD.org> <54D1E558.1010700@FreeBSD.org> In-Reply-To: <54D1E558.1010700@FreeBSD.org> Content-Type: text/plain; charset=windows-1251; format=flowed Content-Transfer-Encoding: 7bit Cc: melifaro@FreeBSD.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 11:04:17 -0000 On 2/4/15 5:24 PM, Lev Serebryakov wrote: > -- > Re-installation of state (with second, third, etc... packet of > connection) should update TCP state of state (sorry!), or it will die > in 10 seconds. > This version seems to be final (apart from name of new option!). > It works perfectly on my router with 2 uplink ISPs. can you put it in the code review system so I can annotate and comment on it? From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 11:11:55 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E5267513; Wed, 4 Feb 2015 11:11:55 +0000 (UTC) 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 B744C24C; Wed, 4 Feb 2015 11:11:55 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t14BBpLf043299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 Feb 2015 03:11:53 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D1FE72.1020508@freebsd.org> Date: Wed, 04 Feb 2015 19:11:46 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: lev@FreeBSD.org, freebsd-ipfw@freebsd.org Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> <54D1AA60.4030907@freebsd.org> <54D1E4D4.10106@FreeBSD.org> In-Reply-To: <54D1E4D4.10106@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.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 11:11:56 -0000 On 2/4/15 5:22 PM, Lev Serebryakov wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA512 > > On 04.02.2015 08:13, Julian Elischer wrote: > >> yes I think "keep-state" should be deprecated and replaced or >> supplemented by 'save_state' that does NOT do an implicit >> 'check-state'.. I don't know whose idea that was but it's just >> wrong. (if the state exists, maybe just replace it..) > Update, not replace :) > See my Version-3 patch for "record-state" :) I meant a function that acts like 'keep-state' except it does not do a 'check-state'. Im suggesting adding yet-another command. a 'fixed' keep-state. I sort of know why they did it.. so that if the state for that session already exists, the original state rule is used and not the new rule. but ..it fires on other packets as well as the one you are working with. > > - -- > // Lev Serebryakov AKA Black Lion > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2.0.22 (MingW32) > > iQJ8BAEBCgBmBQJU0eTUXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w > ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF > QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePoS0P/iCMeTo+fFA4iGwe/8FnlF+y > 899fomt4tzOBppxg1r5/xx11OMB9DJ6VG1z8+61gzIg1jgxvAIBTBGz5oxIgyfv5 > mtbEbfhsxsABYTASjwIQymxR1zvLCbyd7fWgDRhM8YJYEy/akWNzOwtbokrkK1Ww > 3j2IODup3onYr5LhwoQZGPdtmIyH10rnEcs49IWUs1ZweWlJx7XRQOGBAepTQRx9 > bh/D0owV1j9BBzyqd5n54aXiQpMKMIdOihmNOOUYhl0B3GksacWguV7Keabbv0Dh > Nnk3g/GrBYJPdmF0JqkocjrGxSuWAwBXfdXg3SoG8l1dPqaDg8UNVXq7VthS7FKO > 8jyoRXaptbcrTjgG0SHdfnSzbhpLj78/PdGi1VvJwrvjnK2MNb6dZ2PE3E88ScgM > f7OIOef9GyLwgAPqn6TJeiC7Oddvq+vL1vEigqLMJscJ4ErwqX8RVidbkYdNmKCf > HYSd9mSJgkAMUH7q2U5PCRY9Ay6BOkuGHEqvMHGFClqBWb81RTyT8ZR+BL+JeqRr > QNilMWvUXJSGEcvMYijKiv2EVDB6by3sY2SK9KLa93H0jY1nR3XPpilpyLcHLzN9 > 5aVknqR2/TzFDS1BiSEg/wYipyqjgIyHTqqxj0Vd0pnZMSw3AqdrOSLz8mHJzXKp > 3J8Y7Lw7fuM1N8Doq2Md > =/M0i > -----END PGP SIGNATURE----- > _______________________________________________ > freebsd-ipfw@freebsd.org mailing list > http://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 Feb 4 11:23:34 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3CAFA902; Wed, 4 Feb 2015 11:23:34 +0000 (UTC) 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 13CC43FE; Wed, 4 Feb 2015 11:23:33 +0000 (UTC) Received: from Julian-MBP3.local (ppp121-45-238-204.lns20.per1.internode.on.net [121.45.238.204]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t14BNShg043337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 4 Feb 2015 03:23:31 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <54D2012B.6040906@freebsd.org> Date: Wed, 04 Feb 2015 19:23:23 +0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: bycn82 , lev@freebsd.org Subject: Re: [RFC][patch] New "keep-state-only" option (version 3) References: <54D0F39B.4070707@FreeBSD.org> <54D0FD9B.5000108@FreeBSD.org> <54D1E558.1010700@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-ipfw , "Alexander V. Chernikov" , freebsd-net X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 11:23:34 -0000 On 2/4/15 6:08 PM, bycn82 wrote: > /Cool, > But maybe not all people are following this topic, so can you please > simplify it by answering below question in order to allow more > people to know what is going on here. > > / > /What kind of problem you are facing and how does your patch resolve it? > > > / > let me have a go at this: when you write complicated rule sets with state, you start having problems where the state is too broad, or contains things you don't want in the place where you are using it.. sure you want packet/session A to set the state, but you don't want state for session B to trigger there at the same time. this allows you to set a state/action for all future packets in the session without triggering sessions you didn't mean to, or actually doing that action yourself right now. this give you a lot more flexibility in the sets you can create. An example here is combining NAT with session state. You can only have the rule active on one side of the NAT. If you want ot have state on the 'inside' of the NAT then you want outgoing processing to continue on, so that the NAT is then used. However if you try do the check-state on input After the NAT (you need to do NAT on the same 'side' of the NAT for both incoming and outgoing) then you end up having to do various tricks to avoid being diverted into output processing. what you want to do is be able to set a rule that will handle the incoming packets in a way you want but doesn't do the same thing for the outgoing packets. Come to think of it another answer might be the ability to specify different actions for a session for incoming and outgoing, but that would be quite hard to do. at least this way you can specify a rule for input without having to do the same thing on output. there are other drawbackss . like if you have another check-state in the output path, it will still trigger on the packet and do what you didn't expect. but I think this is an improvement. Having said that. I'd REALLY like to have multiple dynamic sets and be able to specify which set I'm looking in. then you could have differnt dynamic rules for NAT'd and unNATed packets, and differnet rules for the same packets as they traverse different interfaces. Lev, I think this is an improvement, but I wonder if we can make it even better. Julian From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 11:33:46 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 26758C14; Wed, 4 Feb 2015 11:33:46 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id D9C606C6; Wed, 4 Feb 2015 11:33:45 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 04B5A5C002; Wed, 4 Feb 2015 14:33:29 +0300 (MSK) Message-ID: <54D20388.7070009@FreeBSD.org> Date: Wed, 04 Feb 2015 14:33:28 +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.4.0 MIME-Version: 1.0 To: Julian Elischer , freebsd-ipfw@freebsd.org Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> <54D1AA60.4030907@freebsd.org> <54D1E4D4.10106@FreeBSD.org> <54D1FE72.1020508@freebsd.org> In-Reply-To: <54D1FE72.1020508@freebsd.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 11:33:46 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04.02.2015 14:11, Julian Elischer wrote: > On 2/4/15 5:22 PM, Lev Serebryakov wrote: On 04.02.2015 08:13, > Julian Elischer wrote: > >>>> yes I think "keep-state" should be deprecated and replaced >>>> or supplemented by 'save_state' that does NOT do an >>>> implicit 'check-state'.. I don't know whose idea that was but >>>> it's just wrong. (if the state exists, maybe just replace >>>> it..) > Update, not replace :) See my Version-3 patch for "record-state" > :) I meant a function that acts like 'keep-state' except it does > not do a 'check-state'. Im suggesting adding yet-another command. a > 'fixed' keep-state. Yep. Maybe, additional option? Which will work only on user level and force to skip generation of O_PROBE_STATE? Now on KERNEL level nothing force this check, it is additional opcode, added by user-level "compiler". Only thing we need to make it work properly is in my last patch for "record-state": add TCP state propagation to "install_state" function to make it able to update existing state properly. and after that you don't need any additional opcodes for "keep-but-not-check-state" command/option, it will be user-level change. > I sort of know why they did it.. so that if the state for that > session already exists, the original state rule is used and not the > new rule. but ..it fires on other packets as well as the one you > are working with. Yep, because O_PROBE_STATE is FIRST opcode always. It is matter of compilation. - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0gOIXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EeP/1sQAKMgZyk3BVCXB8Q+Rmvy/D0K YhPICBbPqUWHw35HfXG0hgw66pa/SX0G68HO2LoxurbxFtu3pdsKA3X8ok4J3Yvb 374MPQcUYFxoUmvjjWUpNMGUBBm72TPk61cjUdsWWJoYWrLJmM0UMJ2wJREvS2D6 s0hUuFGBb/OaTW8aHWY2gAwViPDxR2gQmX8Pw6XpZLxR3ZyNcMTnx78jGn+8jykM tLxmLjlOSAw4XfsbkiG6X7CmkgyFhcN/B6cpRNB8qsLSmG6rzBup6JrAcFYRq/63 LUj8Z0azwJoHqeLBKZ7RfcfqbB9PMdMTaufBPxQVclQntERkN4nEacT4LSRd1aoL 2zEKMV+PN8X4sL3h73laURLq5lHOVuJsG73YGR1n/IPtlkeeLu1zOADjPRd/0ZY+ kOWzvE00RGhb1mt2LNpL9qZQ8oIcf0r3pYuZKmV0vT7BnQ/Pw4lMjcPyHPSJyFgR yn2fslDvytg8e/iPvHuOm6h8t6Um3bAbV2LrW4fHSgbhMPGt/nzwuRicMoj6o+Fx r3q+ITM54QbodBZuS0Ie7IvCNZIfYwwp27GS1lZ8lEv1lYy4kVW9B3AOZzows5XW YWjVz4xzYd3qaTQyoNij9NFJYVx52IXoAP23PFPDhbr1OFhomGVXQCgu/KS3JHOQ kR5C1h4iKmkjLUCmDC/P =sqjh -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 12:34:15 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id E117DBAE; Wed, 4 Feb 2015 12:34:15 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 569E8D3A; Wed, 4 Feb 2015 12:34:14 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t14CYCSm026591; Wed, 4 Feb 2015 23:34:12 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Wed, 4 Feb 2015 23:34:12 +1100 (EST) From: Ian Smith To: Julian Elischer Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny In-Reply-To: <54D1FE72.1020508@freebsd.org> Message-ID: <20150204231922.X38620@sola.nimnet.asn.au> References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> <54D1AA60.4030907@freebsd.org> <54D1E4D4.10106@FreeBSD.org> <54D1FE72.1020508@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org, lev@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 12:34:16 -0000 On Wed, 4 Feb 2015 19:121:46 +0000, Julian Elischer wrote: > On 2/4/15 5:22 PM, Lev Serebryakov wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA512 > > > > On 04.02.2015 08:13, Julian Elischer wrote: > > > > > yes I think "keep-state" should be deprecated and replaced or > > > supplemented by 'save_state' that does NOT do an implicit > > > 'check-state'.. I don't know whose idea that was but it's just > > > wrong. (if the state exists, maybe just replace it..) > > Update, not replace :) > > See my Version-3 patch for "record-state" :) > I meant a function that acts like 'keep-state' except it does not do a > 'check-state'. > Im suggesting adding yet-another command. a 'fixed' keep-state. > > I sort of know why they did it.. so that if the state for that > session already exists, the original state rule is used and not the > new rule. but ..it fires on other packets as well as the one you are > working with. I don't get this .. we're always working on just one packet at any time, either inbound or outbound (to kernel), so how can check_state (or the check also on keep-state) apply to any other packets than that one? I've seen examples that run keep-state on the same packet both before and after NAT, ie state on both the internal and external addresses, which is even more confusing and surely inefficient too. I'm not sure that everyone realises that it's the first check-state or keep-state rule _encountered_ - ie not skipped around - that matters. A good, definitive tutorial on how to best handle stateful, NAT'd rules would be useful, because there are a few different theories in the wild. Personally I only run stateful on a few types of session, and then always using the internal addresses, but that's just one of the ways .. but doing _everything_ statefully seems to be the Holy Grail to some. cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 13:03:21 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4CAB31C7; Wed, 4 Feb 2015 13:03:21 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id CA216E9; Wed, 4 Feb 2015 13:03:20 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 819725C002; Wed, 4 Feb 2015 16:03:09 +0300 (MSK) Message-ID: <54D2188D.5080800@FreeBSD.org> Date: Wed, 04 Feb 2015 16:03:09 +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.4.0 MIME-Version: 1.0 To: Ian Smith , Julian Elischer Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> <54D1AA60.4030907@freebsd.org> <54D1E4D4.10106@FreeBSD.org> <54D1FE72.1020508@freebsd.org> <20150204231922.X38620@sola.nimnet.asn.au> In-Reply-To: <20150204231922.X38620@sola.nimnet.asn.au> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 13:03:21 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04.02.2015 15:34, Ian Smith wrote: > I don't get this .. we're always working on just one packet at any > time, either inbound or outbound (to kernel), so how can > check_state (or the check also on keep-state) apply to any other > packets than that one? Simply enough: assume packet goes from internal network ("in recv em0", say) to external one, ("out xmit em1"). It passes firewall twice, really. In ip_input() (it is matched by "in") and ip_output() (it is matched by "out"). Say, we have "keep-state" for this packet when it is "in" as last action, something like "allow keep-state" to have this state to check answer packet "in recv em1" (note, "em1" here) appropriately. And in "out" section we could have OTHER "keep-state" rule, for locally originated packets (which never pass through as "in" ones). Of course, this, second, "keep-state" is equipped with additional conditions like "src-ip me". Now, our transit packet creates state in "in" section and is passed to "out" section. And it triggers this state on "src-ip me keep-state" rule! It doesn't belong to this rule! But doesn't pass conditions of this rule! It SHOULD NOT BE AFFECTED by this rule, match failed, try next one! But -BANG-! "keep-state" has implicit UNCONDITIONAL "check-state"! So, we need additional stupid skipto like this: XXX skipto ZZZ not src-ip me YYY allow src-ip me keep-state ZZZ nat 1 // out To me, it is stupid, contra-intuitive, non-orthogonal and bad design. I think, there is THREE DIFFERENT things: (1) Creation/updating of state, with normal condition checks on packet. (2) Checking packet against state table, updating state, performing action (if appropriate state is found, of course). (3) Performing action WHEN state is created (not checked!) Now ipfw has very tangled way to do this. We have: (A) (2) + (1) + (3) (in this order, please, note that condition checks are done in (1), not BEFORE this chain). It is keep-state. (B) (2). It is check-state (c) (3). It is stateless rule. That's all! You could not do (1) without (2). You could not do conditional (1). You could not do (1) but not (3). Nothing! And if "conditional (2)" may be too much, but only possible to go to (1) is via (2) and inevitable (3) after that is too much, IMHO! It is very obscure behavior! To be honest, I want add not only "keep-state-only" (pure (1)), but, also have "keep-state-do-action-no-check" to have (1) + (3) without (2). - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0hiMXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePd60P/iTr55i4uyLfa7cf/TH9ypdt S9iP23qGZDPo+YzjVfmcyBNWbYJ2eNfkve9DhYHoizpacqHeepnWfMxNPdSf0kLI lZ0qYt/EtwTDCOoSx+wE/c1ywzvHUKO7k631GS/EpRbUwli5yEZnJEFwJPlEJ8WY A3uBtPxBAn3CEiS7ps91Da260Qt3xgw4Sv99YOzY7k2etUOsj8r2EEkLG8gsH96V Pk4udb17Kc0WygwNN7OaI1mxXaoKkd6NzZM4W0WvWy5fKgD/Rhep5hD4/oFixfsJ HKxjYjUDrzc6/elL5GW1+OwzQ08+KziriRqBT2QMOJnso9a1yQc/5jvO1C4zol9Y wF3ZgcMIAJKBmOdkWHPMfrhNYMutI8gPsKH063BRkHFTtTQb7yL8bysLYE1P23lM hzl3ubZtcas7Z5kBpsAL2L0xXLReMCCTSULv0oQDitb6H4z3eUeN5iq2Sk6b0uwB J6mZiHCYU48KU0ST4/UAnZFYX4mUFTiIfP2KzekdZ+BUNdGgdVr177EJChZxBL4M x/In6x944pwRxCExFa10OSMzQqdOJ+IQEfS1LfG+l/A4X7Rjx87Gbb4A/3ePkkdA HoZLACmRfFGxmWILZa8EtldUvDsOjXs+Q08rpvp2So0szcM0N5XIixDbnLEvCqFu xn6GOWuyaJVzZlpllCV0 =ALXi -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 13:13:02 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id DB170496; Wed, 4 Feb 2015 13:13:02 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id 9BCA825C; Wed, 4 Feb 2015 13:13:02 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 8A7BE5C002; Wed, 4 Feb 2015 16:13:01 +0300 (MSK) Message-ID: <54D21ADD.2090209@FreeBSD.org> Date: Wed, 04 Feb 2015 16:13:01 +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.4.0 MIME-Version: 1.0 To: Ian Smith , Julian Elischer Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> <54D1AA60.4030907@freebsd.org> <54D1E4D4.10106@FreeBSD.org> <54D1FE72.1020508@freebsd.org> <20150204231922.X38620@sola.nimnet.asn.au> <54D2188D.5080800@FreeBSD.org> In-Reply-To: <54D2188D.5080800@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 13:13:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04.02.2015 16:03, Lev Serebryakov wrote: > To be honest, I want add not only "keep-state-only" (pure (1)), > but, also have "keep-state-do-action-no-check" to have (1) + (3) > without (2). Ideally, here should not be implicit "check-state" at all, and should be two options to rule: (1) keep-state (2) skip-immediate-action So, current "keep-state" becomes two-rules: check-state all from any to any keep-state And all other variants are possible too, like keep-state skip-action and meaningless, but still possible, skip-immediate-action It is hard to add now in backward-compatible way, though. But may be... May be... I should think! It looks like doable on second glance, and better (more flexible & orthogonal) that my current proposal! - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0hrdXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePGFcP/0CpmLVadnVjQqC+PLQVpT4E cqLy5RfE4D587JeaXfoDher7J/WJj02NKJWkuhZqkvuZAVvFx5xiyl63X9yR1ASR a8rHGkM9pa4wbQ9XA2YKlhsaVntQtmmk1/qyp9AZecX/aZl6taWualeRCPGgNSvC lP6JdUCTelUIjlGwvsKI4Xu9ljuV59PaYh3SxLXxQSuyr5CA1ayRjT5e6Mp7SLPk gfy38Cq7PmrwrQAtkYfcP8K9fYTpnHaKqXYKpELSIqbpKGUcB0AnloXg9u2fJbmD Ux8lf0MvpDOiw0UfcHaypluLzU0/vuWE9EwyXe4p6GbdWjd9YXwgkbMsCWcR5lbT KJrAo0Jk2//blLFtKNDSLHb3JpKjSQkVRE/dhNOr066m682xnloPxFPE1p1e79P8 9D4Yi/ii2CGR15tP9keNjnDEOvO5JSSD+kHH/elUyuHye++UjKKNJoDCp5JIopFr SJ7NHYyVhlMmIMWIQeXUIRoNxblv9C5C9G2k7nBMlaxWN8VG0AKIerRyHTrEtwzt 0M9Tb6Et7dXULvqR0U+PgXvOLDo+DmmYf5cZiUCsVnLba0UwcWt7i2qWsA9KmQEE ZqTaVz8cJSkHybQLqlGtIwMfWgh7s6XSAjaPgk0OviDNCwTs9Ry/6QRPpCnkcC5p wsN8ML5mL59HqlkIvTxU =gWCG -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 15:13:01 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D1447A30 for ; Wed, 4 Feb 2015 15:13:01 +0000 (UTC) Received: from mail-ie0-f182.google.com (mail-ie0-f182.google.com [209.85.223.182]) (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 9C51C5E2 for ; Wed, 4 Feb 2015 15:13:00 +0000 (UTC) Received: by mail-ie0-f182.google.com with SMTP id ar1so2598200iec.13 for ; Wed, 04 Feb 2015 07:13:00 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=wq+WmeVC8kqevs+OAcWrV5NoyrhxlcZqcmHsmlqi9iA=; b=KYsGHveyu8NQLHjsqrFFGb1NQVPE+yA+VenPLKcCU3xzgWMf9i/73WDvHNcMUwyPwV jPABlh4gRaLhQ13L2LShQyFeb92PP7MdabAQ1PMqjuDbo9BsJNss7e5VTRj6YNznpb2l yHT7oQfHMlwWtAzNwLxkE423d/i5XBTxD+BS3unOIXCHbK70N5d6Rola2Cq1bCCxM8LQ XnVCZcBU2O/J/rYSBC3iTgIp1SOuEBaKp7g0KlNIBWMygXAdmkmJPkCsYO242lp9XhTJ NSKrw4JJrAscy42Joi+sTLXsPu2AhvYLmMaDiAgGiGdwBuh1oXQgDoZSF5vvQoKRibra 4xsg== X-Gm-Message-State: ALoCoQl4wAbINPlzXr/MoXPIp4XUxi1U/fagY8a/PtWH2BMG3cVr8O/90tUBbeNyAfgIeTuSUDjV MIME-Version: 1.0 X-Received: by 10.42.199.211 with SMTP id et19mr2268601icb.9.1423062780348; Wed, 04 Feb 2015 07:13:00 -0800 (PST) Received: by 10.36.68.138 with HTTP; Wed, 4 Feb 2015 07:13:00 -0800 (PST) X-Originating-IP: [2001:470:8747:1705:f8f1:55e8:121e:8fd1] In-Reply-To: <54D21ADD.2090209@FreeBSD.org> References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> <54D1AA60.4030907@freebsd.org> <54D1E4D4.10106@FreeBSD.org> <54D1FE72.1020508@freebsd.org> <20150204231922.X38620@sola.nimnet.asn.au> <54D2188D.5080800@FreeBSD.org> <54D21ADD.2090209@FreeBSD.org> Date: Wed, 4 Feb 2015 08:13:00 -0700 Message-ID: Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny From: Jason Lewis To: lev@freebsd.org Content-Type: text/plain; charset=UTF-8 Cc: freebsd-ipfw@freebsd.org, Julian Elischer , Ian Smith X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 15:13:01 -0000 The possible issue is is that once NAT changes the IP address and possibly the port number, state tracking can no longer be applied. AKA, the packet headers before the NAT is different than the packet headers after. This is why NAT needs to track the state instead of ipfw. From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 15:20:01 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED8ACB4A; Wed, 4 Feb 2015 15:20:01 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id AA3D2638; Wed, 4 Feb 2015 15:20:01 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id ABD1C5C002; Wed, 4 Feb 2015 18:19:49 +0300 (MSK) Message-ID: <54D23895.5090701@FreeBSD.org> Date: Wed, 04 Feb 2015 18:19:49 +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.4.0 MIME-Version: 1.0 To: Jason Lewis Subject: Re: [RFC][patch] Two new actions: state-allow and state-deny References: <54CFCD45.9070304@FreeBSD.org> <20150203205715.A38620@sola.nimnet.asn.au> <54D0A1AA.4080402@FreeBSD.org> <54D1AA60.4030907@freebsd.org> <54D1E4D4.10106@FreeBSD.org> <54D1FE72.1020508@freebsd.org> <20150204231922.X38620@sola.nimnet.asn.au> <54D2188D.5080800@FreeBSD.org> <54D21ADD.2090209@FreeBSD.org> In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org, Julian Elischer , Ian Smith X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 15:20:02 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 04.02.2015 18:13, Jason Lewis wrote: > The possible issue is is that once NAT changes the IP address and > possibly the port number, state tracking can no longer be applied. > AKA, the packet headers before the NAT is different than the > packet headers after. This is why NAT needs to track the state > instead of ipfw. If you create state and check state on proper "ends" of NAT (for example, create state for connection BEFORE out-NAT, with internal addresses, and check it AFTER in-NAT, with internal addresses again), it will work. But now, when state creation is terminal action AND state checking in one box, it is hard to implement and leads to very non-intuitive rule sets. - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0jiVXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePTnQP/2kxqyTxUSa3RBLBsoq58iL4 IeGarQ7PrTVVaBTEVzhabU0yPuORpMqrwf47nImAZQWHcQP7UUjO+VjjqDthwwe8 S3CElbPFW86HmYLB7Nz1Lhg7n0eaKG6xxDO5um/b3cWuK7B3DiU+9oW7OHICF0Xa mk5Z9koVuAS3yuvT6PecSRgziV6HgxEKgYgNCgN+JmXWlL/H8kYUuYKBQTv1snkw hcRLKrRp31KavH8CRiTf6uBCozS4URvr6xRSfrkjcuU9LUlvHcI6jBCm7yOAEeDH HkcU5g5mNSK0vdJXZVmtveFADs8RrtAtovxt4FQZCjYPBhCDMRvM9IPQX8eK8tKX 8efJHb6DPIZQs+AeEhL1jeNJTu/UJRUag65Aua7TXq7jcopOMHM85aNMs6FzyqeG eT5Epc+oZ0Zbi0RAZzqvUeQSnARPE4tGddoOK5z5YMbF0jSiHM5ftfYncOp8YvDE uJMQAHOU4CHfuK/knzNkZ4VoD3+i+/fIiR4knNCLCe1wOvY9QmI+3iyk6JGZ4GJ9 vc7W+XCSnfuhFq5+o/8Lr+50z2qpmkJVaWoRW4DItWiHrWbx6dngL2aY8+e7TjEk 24rRQb16uYC6w3dUkNiKHMtUEaN+Zzju186jbQZpPjX6Rz4/9i2DJ6qYiZDWV28x e5TUOek2WeiROK+VvF/2 =XfPm -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 17:20:04 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AE898F30; Wed, 4 Feb 2015 17:20:04 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id 701567B5; Wed, 4 Feb 2015 17:20:04 +0000 (UTC) Received: from [127.0.0.1] (nat.in.devexperts.com [89.113.128.63]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id AF21A5C002; Wed, 4 Feb 2015 20:19:47 +0300 (MSK) Message-ID: <54D254B4.5030207@FreeBSD.org> Date: Wed, 04 Feb 2015 20:19:48 +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.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org Subject: [Differential] [Request, 190 lines] D1776: New options for ipfw - record-state, set-limit and skip-immediate-action - for simpler rulesets Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: melifaro@FreeBSD.org, Julian Elischer X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 17:20:04 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 Looks like, there is no "freebsd-ipfw" mailing list from Phabricator's point of view. Please, review & comment! https://reviews.freebsd.org/D1776 - -- // Lev Serebryakov -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0lSzXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePah4QAIv6YNwQubxEIyqE8GqZlbhm 6fLnRNWI35QHEFtfdlqrtFj5TcArY3o529hQXj6Fjhmu/XQyonH7IBpshiXBUXs/ GIGHaQqXaIsZtiAPhhqpBBta+yp3q8oDg541uDYgRz0IYIrmEPsVIoCDiwW+aWec SmSDmdJyvDy+mAOUujSM47j7dcvirKdIOthJWi3Wjnrtjpd/wEfyduRAft30zi04 88ELKxD9t8t5KvHmPer2FLGRAg7wY1OWUWHxeBCrIkAgKg6anajfUPyIqbomJoI4 IQwJN5GRqJDVvR/3c7W4ifHcNKa7FNFvpKUDwTlBJqWphWIMzVtuoDWZ2aCJlQ5E nwmNuLuzIPGtyFDg1oCMJxx5YWfXQzbYaCECmE9jveg3PU6QpcgbHb3FzJOXR/kA Bt9nkodRldULAXSVfigDk6ZzTq5XgqutPjkgpBHAXGmIMsPGfJU/t18wmR/Hkrhq 8esEpGD9lLkZty/sLG7k5fqeeJI6PZPieui+m2Jy31phUWg7O3FJmqH7Fm2BkeRu FvAR40wd5y8pt6odtKsb9M3kpCoNu5vrigPCPDL92Q+V+lWLsV4eJLoptKnYYTdc pePqP+wqYOH/IAM8XQUFsxBOuKD5goUcNdPDh57pmCDJR2zgfvEmywSez9KuS+Pa 3MwtCcW/PGzjAivBx0iE =Bedo -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 22:16:09 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 38DF3502; Wed, 4 Feb 2015 22:16:09 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [IPv6:2a01:4f8:131:60a2::2]) by mx1.freebsd.org (Postfix) with ESMTP id F1792E74; Wed, 4 Feb 2015 22:16:08 +0000 (UTC) Received: from [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f] (unknown [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 7F6D25C002; Thu, 5 Feb 2015 01:15:56 +0300 (MSK) Message-ID: <54D29A21.2080006@FreeBSD.org> Date: Thu, 05 Feb 2015 01:16:01 +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.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: does "nat redirect_port tcp" works for you on -CURRENT? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 22:16:09 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 I have such rules in my firewall: nat 9 config redirect_port tcp 192.168.134.2:16881 16881 redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp 192.168.134.2:22 22222 nat 1 config ip $EXT_IP same_ports ... // Packets from outer world 11040 nat 9 // Redirection? 11050 nat 1 dst-ip $EXT_IP // De-NAT what should be de-NATed (not redirected by previous) 11060 check-state 11070 skipto 30000 // Allowed local services - common block ... ... 30030 allow proto tcp dst-ip 192.168.134.2 dst-port 22 setup keep-state 30040 allow proto tcp dst-ip 192.168.134.2 dst-port 16881 setup keep-state 30050 allow proto udp dst-ip 192.168.134.2 dst-port 16881 keep-state ... And looks like TCP redirection doesn't work. Counters on rules 30030 and 30040 is strictly zero and "ssh -p 22222 $EXT_IP" (from external host) doesn't work. Rule 30050 (udp one) HAS counters increased, but what is REALLY strange, is that 11040 and 11050 (two NAT actions) always have SAME counters, as if 11040 never change destination address. Nut 30050 sees some packets! Is "nat redirect_port tcp" broken in -CURRENT or do I do something wrong? - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0pohXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePjNkP/3msSEuRm6RWuGGVqIddHzki k2oh5YfbjfXC6hP4XumouqHojbHoHfNqv6yOet31xFwscnX71Q7LVSTF95jhbu9J jJrF2PDkPh+d6XagtuLaAHBvG3PRS61vgW9kl00/IiiemPfA/r10vcXz1TixdLgB bI/N0OFQyz9YXwWWEwZNywAOLaUTYD1FM2F5FtbwGvedlhBcmC08h1D5M1Vk2mF5 P/2ZocAECUeRPW5/JRg6kcnA3nJ8CVJr08I1IqQEsaQifRAOFfYcVSdb9DbK5Hms z6nVaJSwi6D1QtxR4x3BNoqGD8o3oc5YWW8obsV6uYzxfZcew2OoyiRgTMDuoBho 73q6WmUlvlvFB1PCOCGr8YxzHPpQZ7KP8NMKoSM8CiAT0/n5qY9CJGOxcf2Q4EEv tErw/TkjAXmzxGDj0ZZBjjvWE7kIhSk9HgXfzF3XL3FasmcV5Iu+JeSswlPtpHyD RCfB84rUcjmldpGZVs9OXD3+jJpY2JaXNrDmdM7elVr9d/CvM1IDkm62N9b9Pqjr uE4VKyipVrbsb06INchz9Gg5D1LhTbBCWoB6mo/5F1dYBkpSqezVUMsibcKvLbeR 9cBkL+iQif1Q8TmfIMYBwbqcfIx6MhbOxhtAiHR3QECc1IJ6Vn3/hrcVzB/PXc4Y SQU7uy3TpJH320nN1BDV =aAlm -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 22:20:49 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 250DA656; Wed, 4 Feb 2015 22:20:49 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id D9A28EB2; Wed, 4 Feb 2015 22:20:48 +0000 (UTC) Received: from [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f] (unknown [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id 241DA5C002; Thu, 5 Feb 2015 01:20:47 +0300 (MSK) Message-ID: <54D29B44.1060603@FreeBSD.org> Date: Thu, 05 Feb 2015 01:20:52 +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.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: does "nat redirect_port tcp" works for you on -CURRENT? References: <54D29A21.2080006@FreeBSD.org> In-Reply-To: <54D29A21.2080006@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 22:20:49 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05.02.2015 01:16, Lev Serebryakov wrote: > nat 9 config redirect_port tcp 192.168.134.2:16881 16881 > redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp > 192.168.134.2:22 22222 Also, if I add "log" to this config: nat 9 config log redirect_port tcp 192.168.134.2:16881 16881 redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp 192.168.134.2:22 22222 I could not print this log: # ipfw nat 9 show log ipfw: unknown redir mode ipfw nat 9 config log# Configuration printing is Ok: # ipfw nat 9 show config ipfw nat 9 config log redirect_port tcp 192.168.134.2:16881 16881 redirect_port udp 192.168.134.2:16881 16881 redirect_port tcp 192.168.134.2:22 22222 # - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0ptEXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePphIQALKqUuR7wGZGlJaR58arzYZi boLuUxCSoM98UBO58egLeEgn7CKVxt34JRH6OwjDh18KeocfYr92LoYCpt6324dM rjQqy4PdYda91aW+46qUFFY1n3i55AB+WfLDdmUNivqGn+ouKnSHdoFMknvG+bnC n1DZIEiUpbE5ZnlA6XJ3nZUpmmKVTpHBWemEzF/Vn3f8A9ShJlI3fmK3+eh+SH59 B6k4IgcGryDsskCBuRTam+dYq89+a0wSVyzcrNiYLxikPy+wE2bCwY8tE63I5khZ 7MAuSVlgaOq+CvJmKRQ+522h3H5w6eco/wQokq1IyhpBeLNwI55BfY5jZdll9/M8 c6d5yho85VzXbNbTi2XXSWAmi9xYw6Pag4dA8iaLe2Mdoh8klgtOKBVo9uNw7ywX WS7/NyhlmMvJffStdO2t88awEV5NNE5lYeCmCstK3zZ+m7feKDynhHrUqOoXaZux 7tylx0J0rihdULZH1PyceO6y9aGRKfdoes0oiUc3ovumUunmFrTUdkEgodTG2nEo CPSlvy5rthL634b1NSBIrdHPGYo+6IQR3s4MaTs/RvdIVQHoZrl4XtKz8h904Fl4 MuYCfNI4E7I/AV6n3rbidQvfgosu4+wtR+4tZ8iV7gTLNZEZ6DiyXn8Ab3sNKuLC LjOfhudWDkmfumCqIkNE =hZrV -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Wed Feb 4 23:14:42 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 34086A1; Wed, 4 Feb 2015 23:14:42 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id E93677D3; Wed, 4 Feb 2015 23:14:41 +0000 (UTC) Received: from [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f] (unknown [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id AFE5F5C003; Thu, 5 Feb 2015 02:14:35 +0300 (MSK) Message-ID: <54D2A7E1.2020902@FreeBSD.org> Date: Thu, 05 Feb 2015 02:14:41 +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.4.0 MIME-Version: 1.0 To: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org Subject: Re: does "nat redirect_port tcp" works for you on -CURRENT? References: <54D29A21.2080006@FreeBSD.org> In-Reply-To: <54D29A21.2080006@FreeBSD.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Feb 2015 23:14:42 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05.02.2015 01:16, Lev Serebryakov wrote: > I have such rules in my firewall: > > nat 9 config redirect_port tcp 192.168.134.2:16881 16881 > redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp > 192.168.134.2:22 22222 > > nat 1 config ip $EXT_IP same_ports One more datapoint: if I merge this to one NAT (and change rules accordingly), redirect work as expected. But I have TWO different NATs in full config (for two ISPs) and don't want to duplicate all redirection specifications, but want to use third "common" NAT config. And such usage is shown in ipfw(8)! - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0qfhXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePtxMQAMg/YeLuNTP4KzKAGb8Z0AXc RLMdopJaZ81R5f4LnWtcQR1n0hzdLRhsmFvPLuHUdB6RgFbJ+TreMZq4h5IMLivy Wig9Uljhjkd6nS415ca4pQSrd9fzymI69WTLq/WSHwgxv6ngeT1x97cNh20R9VuD 3tPxj70Lf5IhtHB4MePpb3mh+iaLuaB9pizoP57M7YghN5qjvgXnaDRPamWiCfJl moUAXL1OQ0wInz1G9Z08nXJQz33mcJWlBNlPUc6n58nGjJGrgtNQL7sNCbs9yvVg +3+bHVH1e6v0BVuDKfEpYPP9KjCCLPWQvh7IgMpjur4fUBpe2TGVo+PS5i8ndakF KGvhmqJYsENuyh4GbiyQPN6kbDXXWl/PnUDKmtRHAdFMPLYOPkrgH4WJgHOU2zuR +iOmT5pmhG/9lb8yrNy8gmWgoj8XUvA/RlCHNtqzKVX9A6cFk+Tg5XMYSGbFlWYL h/O72zcSc7HQ/bsgj2sDT8ohfyIRCo9PtQPXtC2t0rdrDRQllCGNRALnUk8C0K2+ 4cYN4R3fIEjIBXAl6eCPlBDJEzS+WnXNNea1qIlW54vP5JmtQ7AMaSl0teUxNInU 8V4OUl+R9XMG456Ri370abfFHIr8PN63G9FhfCjWAPzyAYLR48HooGcCZN9Zzz4L vYxM8Xo9xKtuV9G9E8f0 =GIA1 -----END PGP SIGNATURE----- From owner-freebsd-ipfw@FreeBSD.ORG Thu Feb 5 05:08:22 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 9A4225DB; Thu, 5 Feb 2015 05:08:22 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1EA011C2; Thu, 5 Feb 2015 05:08:20 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t1558FBO061675; Thu, 5 Feb 2015 16:08:17 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 5 Feb 2015 16:08:15 +1100 (EST) From: Ian Smith To: Lev Serebryakov Subject: Re: does "nat redirect_port tcp" works for you on -CURRENT? In-Reply-To: <54D2A7E1.2020902@FreeBSD.org> Message-ID: <20150205160544.D38620@sola.nimnet.asn.au> References: <54D29A21.2080006@FreeBSD.org> <54D2A7E1.2020902@FreeBSD.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-ipfw@freebsd.org, freebsd-net@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 05:08:22 -0000 On Thu, 5 Feb 2015 02:14:41 +0300, Lev Serebryakov wrote: > On 05.02.2015 01:16, Lev Serebryakov wrote: > > > I have such rules in my firewall: > > > > nat 9 config redirect_port tcp 192.168.134.2:16881 16881 > > redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp > > 192.168.134.2:22 22222 > > > > nat 1 config ip $EXT_IP same_ports > One more datapoint: if I merge this to one NAT (and change rules > accordingly), redirect work as expected. > > But I have TWO different NATs in full config (for two ISPs) and don't > want to duplicate all redirection specifications, but want to use > third "common" NAT config. And such usage is shown in ipfw(8)! Just curious .. what's your value of net.inet.ip.fw.one_pass? And does all of this really need cross-posting to net@ as well as ipfw@? cheers, Ian From owner-freebsd-ipfw@FreeBSD.ORG Thu Feb 5 09:25:05 2015 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 0B4A313C for ; Thu, 5 Feb 2015 09:25:05 +0000 (UTC) Received: from onlyone.friendlyhosting.spb.ru (onlyone.friendlyhosting.spb.ru [46.4.40.135]) by mx1.freebsd.org (Postfix) with ESMTP id BF382BFD for ; Thu, 5 Feb 2015 09:25:04 +0000 (UTC) Received: from [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f] (unknown [IPv6:2001:470:923f:2:c806:d810:44dc:8c6f]) (Authenticated sender: lev@serebryakov.spb.ru) by onlyone.friendlyhosting.spb.ru (Postfix) with ESMTPSA id C87515C002; Thu, 5 Feb 2015 12:24:46 +0300 (MSK) Message-ID: <54D336E5.2050809@FreeBSD.org> Date: Thu, 05 Feb 2015 12:24:53 +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.4.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: does "nat redirect_port tcp" works for you on -CURRENT? References: <54D29A21.2080006@FreeBSD.org> <54D2A7E1.2020902@FreeBSD.org> <20150205160544.D38620@sola.nimnet.asn.au> In-Reply-To: <20150205160544.D38620@sola.nimnet.asn.au> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Cc: freebsd-ipfw@freebsd.org X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Feb 2015 09:25:05 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 05.02.2015 08:08, Ian Smith wrote: >>> nat 9 config redirect_port tcp 192.168.134.2:16881 16881 >>> redirect_port udp 192.158.134.2:16881 16881 redirect_port tcp >>> 192.168.134.2:22 22222 >>> >>> nat 1 config ip $EXT_IP same_ports >> One more datapoint: if I merge this to one NAT (and change rules >> accordingly), redirect work as expected. >> >> But I have TWO different NATs in full config (for two ISPs) and >> don't want to duplicate all redirection specifications, but want >> to use third "common" NAT config. And such usage is shown in >> ipfw(8)! > Just curious .. what's your value of net.inet.ip.fw.one_pass? 0! But I found problem: LibAlias could not found link with empty "alias_addr". So, you need have one. Global ("nat config ip ...") or redirection-specific (redirect_port tcp 192.168.134.2:22 :22222). I'll try to fix it. > And does all of this really need cross-posting to net@ as well as > ipfw@? I'm not sure :) CC: removed. - -- // Lev Serebryakov AKA Black Lion -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQJ8BAEBCgBmBQJU0zblXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGOTZEMUNBMEI1RjQzMThCNjc0QjMzMEFF QUIwM0M1OEJGREM0NzhGAAoJEOqwPFi/3EePB+wP/2VESImjMft6/1zpYfNo8eK5 jE4IwMgFF2Q91a1Ggr1VqsawW8f2hZnI2rLRzE7NioK8QRuq6T42DEGVk7pZJWKL xNoSBis7NxUh82ShiDJEyb+yXYOTOMFO8guDhE+zZ3hwAbG3uyjSk5LANKBV7XLT miA7z5DT85POJsijk4jPAa9L+UdJIT+vXeZZV/vQ1Xr7B1ImWu4ANGZPQ+A+wvEV ZPnV0dump5nZaUhR0CyPnCUU4tgn0WZS5K0qGjeyjaD5kjDktQ03tsz2m2JHUkM3 niK57PtwgTk8awaN2sZ+eSwj8Fvm0ffy+v/5grdd9GFOCPMYRsRCc9E7oGW7lG84 Wx4Bo3XXNteAXynlYwMS000gkRJCn9J2uFrMi+kLZXJFMI/S5vu2D/9TX6Z7jfvT wtUgZDGk/OWvDVEUH1Ru8gMrbd3jTi+wozDc7eCV7eScGCr/X5HqqxMLqchW6yYe d6KCpENzRTOAHWvKByHq/4xPZnkiFdGnDdJCMzQNd9H/uOdZ6CdFVYrA4qxrUBTU l20+kmEOtm12fRMnlDU1dML1NBPMsfCUIkkoGygJtFNTIxN8QZXysgWMMDMlg+1L 8Bl2QaFNLfueEfi7Vr+QZF9GEYrUU1Xtib9YBFMBmBWDB3YoLKa+r1gdtb2wSsUQ L6Clfv8DZHIdssCgIxFA =CdEJ -----END PGP SIGNATURE-----