From owner-freebsd-ipfw@freebsd.org Wed Jul 29 14:23:46 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 E9E8F9ADE7E for ; Wed, 29 Jul 2015 14:23:46 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: from mail-vn0-x231.google.com (mail-vn0-x231.google.com [IPv6:2607:f8b0:400c:c0f::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 A399D1EEC; Wed, 29 Jul 2015 14:23:46 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: by vnaa140 with SMTP id a140so2775696vna.2; Wed, 29 Jul 2015 07:23:45 -0700 (PDT) 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=mOMRrHccQUY0rx/uwKKeqCER7cpSLR9tN+/SsEeSw4w=; b=NntNP5F0tuDBYt7RJaHlAkzHMgCWO2yjO9WSRt99W97/w1/WN28luspmXTrqiZTONI V5fHBu/IzPR8FJz2+tD8NuNTaP9fBhx8jM8GuWiBcoyKiOH+gWn3wFzLNj/Dr0t2cxAW ZyyRZOFr1NVDE0eqEoM44eyAlw12H04mx2YngY/tn41umwMB77mkpfqcs066XJ9Ju9qN 7kctb6e+Uy0fC41anKILKEsu/86MZl+LpGNchGlEvRvuhJpB8/aIN8LcOG3ppkZjLOr7 nmvotoHNBQh236RlTKWQ0IhNhz9pIYGi55VCq6InJimGJYSY/RwVGV1HPYehO+oW0ooB oNCA== MIME-Version: 1.0 X-Received: by 10.52.72.84 with SMTP id b20mr53025182vdv.6.1438179825612; Wed, 29 Jul 2015 07:23:45 -0700 (PDT) Received: by 10.31.174.6 with HTTP; Wed, 29 Jul 2015 07:23:45 -0700 (PDT) In-Reply-To: <55B8DD3D.1030900@freebsd.org> 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> Date: Wed, 29 Jul 2015 22:23:45 +0800 Message-ID: Subject: Re: keep-state and in-kernel NAT exposes local ip on external interface From: bycn82 To: Julian Elischer Cc: freebsd-ipfw Content-Type: text/plain; charset=UTF-8 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 14:23:47 -0000 *Hi,* *But I dont understand why you said C->D is already in the dynamic table? which line create the dynamic rule for it?* *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" >> > > >