From owner-freebsd-ipfw@freebsd.org Wed Jul 29 19:34:49 2015 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 650C09AD038 for ; Wed, 29 Jul 2015 19:34:49 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 43E546DC for ; Wed, 29 Jul 2015 19:34:48 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (ppp121-45-239-102.lns20.per1.internode.on.net [121.45.239.102]) (authenticated bits=0) by vps1.elischer.org (8.14.9/8.14.9) with ESMTP id t6TJYgJ5061671 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 29 Jul 2015 12:34:46 -0700 (PDT) (envelope-from julian@freebsd.org) Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface To: bycn82 References: <1435692039.18121.12.camel@yahoo.com> <5594395D.6050103@FreeBSD.org> <20150728150845.V17327@sola.nimnet.asn.au> <55B7DB52.7010504@FreeBSD.org> <55B8833B.3030205@freebsd.org> <55B8DD3D.1030900@freebsd.org> Cc: freebsd-ipfw From: Julian Elischer Message-ID: <55B92ACC.6090505@freebsd.org> Date: Thu, 30 Jul 2015 03:34:36 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.20 X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jul 2015 19:34:49 -0000 On 7/29/15 10:23 PM, bycn82 wrote: > /Hi,/ > /But I dont understand why you said C->D is already in the dynamic > table? which line create the dynamic rule for it?/ /it happened on a previous packet at some other rule, for example 30 allow ip from any to D 80 keep-state / > / > / > /Regards,/ > /bycn82/ > > On 29 July 2015 at 22:03, Julian Elischer > wrote: > > On 7/29/15 5:26 PM, bycn82 wrote: >> /Hi Julian,/ >> / >> / >> /So below are the rules in your example/ >> / >> / >> /5 skipto 10 from A to B >> / >> /6 skipto 11 from any to any/ >> /10{action} from A to B keep-state/ >> /11{action} from C to D/ >> / >> / >> / >> / >> /If I remove the "skipto" rules they will become/ >> // >> /10 {action} from A to B keep-state/ >> /11 {action} from C to D / >> / >> / >> /Correct me if I was wrong, but in my opinion, the rule 5 and >> 10 are almost the same, so I dont see the benefit by >> introducing the "skipto" rulees. //IMHO, the "check-state" is >> to speed-up some selected packets, it will slow-down all other >> unexpected packets at the same time./ >> / >> / > /so because C -D is already in the dynamic table it triggers on > 10 and never reaches 11. > see? you fell for it too. > > / >> >> /Regards,/ >> /bycn82/ >> >> >> >> >> On 29 July 2015 at 15:39, Julian Elischer > > wrote: >> >> On 7/29/15 3:43 AM, Lev Serebryakov wrote: >> >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA512 >> >> On 28.07.2015 08:30, Ian Smith wrote: >> >> I have global lack of any spare time (and all my >> FreeBSD activity is >> only a hobby) for last ~2 months. I see the end of this >> unfortunate >> state of affairs in near future and I remember about >> these examples. >> >> >> there are some simple examples of things this patch addresses.. >> For example in the current code, the following (extemely >> simplified) set of >> rules will not do what you would think when you are working >> with a tcp >> session from A to B and another from C to D *which has >> previously been** >> **accepted with a keep-state at some other point in the >> ruleset* >> >> >> 10 {any action} from A to B keep-state >> 20 {any action} tcp from C to D >> >> because despite the fact that you are only triggering on a >> 'setup' packet for A to B, any rule >> that includes "keep-state" does a "check-state" implicitly. >> so the packet from C to D never gets past rule 10. >> the only way you can do this is to prefix rule 10 by >> something like >> >> 5 skipto 10 from A to B >> 6 skipto 11 from any to any >> >> to make sure packets that are not A to B do not hit the >> hidden 'check-state' . >> >> this is a very simple example and yes there are ways to >> get around it, >> but it complicates the ruleset and increases errors >> >> that reminds me I'd also like to be able to put a "not" at the >> front of the rule matching to negate the whole test but it >> doesn't seem to like that. >> >> >> >> >> _______________________________________________ >> 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 >> " >> >> > >