From owner-freebsd-ipfw@freebsd.org Thu Aug 4 18:14:13 2016 Return-Path: Delivered-To: freebsd-ipfw@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2B734BAE2B7 for ; Thu, 4 Aug 2016 18:14:13 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 776A713D9; Thu, 4 Aug 2016 18:14:11 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id u74IE5ve008153; Fri, 5 Aug 2016 04:14:06 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 5 Aug 2016 04:14:05 +1000 (EST) From: Ian Smith To: Julian Elischer cc: "Andrey V. Elsukov" , lev@freebsd.org, freebsd-ipfw@freebsd.org, "Alexander V. Chernikov" Subject: Re: IPFW: more "orthogonal? state operations, push into 11? In-Reply-To: <3c3d7026-ea60-c0dd-527b-edd841274585@freebsd.org> Message-ID: <20160805034606.K56585@sola.nimnet.asn.au> References: <9229d4f7-8466-57b0-c954-117736102bd7@FreeBSD.org> <5755F0D3.9060909@FreeBSD.org> <5759DB79.10205@FreeBSD.org> <3d09497c-136c-e217-154c-ba00e6879c6f@freebsd.org> <20160616005016.A15883@sola.nimnet.asn.au> <64d6bdea-fa32-f16f-2fdd-abd33d54d04e@freebsd.org> <46d5cfde-c4ac-ebd0-3c13-2759037621f3@FreeBSD.org> <11a5d41b-109a-434b-e8e0-7ed2826a8cc9@FreeBSD.org> <6c2ebc59-c5b8-5be0-8842-897b2de44d1f@FreeBSD.org> <3c3d7026-ea60-c0dd-527b-edd841274585@freebsd.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Aug 2016 18:14:13 -0000 On Fri, 5 Aug 2016 00:12:37 +0800, Julian Elischer wrote: > On 4/08/2016 6:50 PM, Andrey V. Elsukov wrote: > > On 04.08.16 06:42, Julian Elischer wrote: > > > so it's a combination of #1 and #2 in my list. I think I originally > > > thought of having just #1. > > > > > > A combination is less useful for me as you need to do: > > > > > > 20 skipto 400 tcp from table(2) to me setup record-state > > > 21 skipto 400 tcp from table(2) to me setup > > > to make the entire session do the same thing. > > So, in your example what wrong with just using keep-state? > > "record-state without immediate action" == "keep-state without implicit > > check-state" needed to solve issues with NAT or something similar, that > > was described by Lev. > > > because keep-state is a check-state for ALL packets going past, regardless of > whether they match the pattern. > > at least that's what I have observed. Except now(?) with named states/flows/whatever, isn't it the case that check-state [flowname] only affects packets with same state/flowname? So you can clearly separate, say, packets on different interfaces, packets coming or going on any interface, and such? If I'm understanding that right - quite possibly not! - then only those packets will match, and others with other names (including 'default') won't match states with that name. I'm not sure I'm expressing this at all well, because I'm only just starting to get any sort of grip, but I'm liking the idea and wondering if it's sufficient for starters. To me, orthogonality implies the least number of commands/instructions that will accomplish the desired functionality. First, let's find out what can and cannot be accomplished with named states/flows .. I'm yet to understand what record-state-without-action can accomplish apart from that .. it could work only for the first packet I suppose, since once state is established, further packets will match and follow state, no? Again, I find concrete examples - like the use of valtype skipto,fib mentioned above - really helpful, essential really, for bears of such little brain as I .. cheers, Ian