From owner-freebsd-ipfw@freebsd.org Thu Aug 4 16:33:54 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 EEA14BAF42F for ; Thu, 4 Aug 2016 16:33:54 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from smtp.rlwinm.de (smtp.rlwinm.de [IPv6:2a01:4f8:201:31ef::e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B36C917B1 for ; Thu, 4 Aug 2016 16:33:54 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from vader9.bultmann.eu (unknown [87.253.189.132]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.rlwinm.de (Postfix) with ESMTPSA id 7710E2342 for ; Thu, 4 Aug 2016 18:33:44 +0200 (CEST) Subject: Re: IPFW: more "orthogonal? state operations, push into 11? To: freebsd-ipfw@freebsd.org 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> From: Jan Bramkamp Message-ID: <458591fc-8118-a3a4-071b-4f581687ee53@rlwinm.de> Date: Thu, 4 Aug 2016 18:33:43 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <3c3d7026-ea60-c0dd-527b-edd841274585@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.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 16:33:55 -0000 On 04/08/16 18:12, 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. According to the documentation and my experience it is. As a workaround i use skipto $stateful + record-state. That way each stateful match continues processing at $stateful. Whilte it works it's hard to understand when combined with in-kernel NAT, because you end up with asymmetric paths through the ruleset for incoming and outgoing packets.