From owner-freebsd-ipfw@freebsd.org Wed Jul 29 09:26:14 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 715219AE8BF for ; Wed, 29 Jul 2015 09:26:14 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: from mail-vn0-x229.google.com (mail-vn0-x229.google.com [IPv6:2607:f8b0:400c:c0f::229]) (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 0F17C1CE5; Wed, 29 Jul 2015 09:26:13 +0000 (UTC) (envelope-from bycn82@gmail.com) Received: by vnaa140 with SMTP id a140so1088268vna.2; Wed, 29 Jul 2015 02:26:12 -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=PF1Q9mZe1OXDOuWOAEJqXIv2LLQ3JzI9u8D2Miff+pU=; b=GfwryP6gPnMKzo4uqgT/gdthKqwD4l0dRp8h9OyXcOEeNO6S6WGgDYaj4oiZ049OHu CTuMzZbHTTxEzBVNunz0j0X7UOpRYZipm2ZHvooEgSZYlL7ZANts2RlzUsibTaS7n9K6 TTjvrqMou1rPAyjPVEOlis3h1bOpA8RoGQyDXoMH7LORTjpXWLijQNm/+OcoI0Ko6HYv NA8FEX2CXYVj6TnCUroGHOmshh3uPPU3gUqdZGNHL7dkbFdTKxF2coSt1JIc39ry5+37 m4rCv9YrLagUUHSR7Ifldp2i60Xq0JQW1MySzm2MLGkiriRHICsnDDauC6MfUb4ZpEzn zPwA== MIME-Version: 1.0 X-Received: by 10.52.12.103 with SMTP id x7mr50633999vdb.70.1438161972010; Wed, 29 Jul 2015 02:26:12 -0700 (PDT) Received: by 10.31.174.6 with HTTP; Wed, 29 Jul 2015 02:26:11 -0700 (PDT) In-Reply-To: <55B8833B.3030205@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> Date: Wed, 29 Jul 2015 17:26:11 +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 09:26:14 -0000 *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.* *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" >