From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 06:22:57 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 37B9316A4E5 for ; Tue, 11 Jul 2006 06:22:57 +0000 (UTC) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (insomnia.benzedrine.cx [62.65.145.30]) by mx1.FreeBSD.org (Postfix) with ESMTP id 72FA443D7D for ; Tue, 11 Jul 2006 06:22:45 +0000 (GMT) (envelope-from dhartmei@insomnia.benzedrine.cx) Received: from insomnia.benzedrine.cx (dhartmei@localhost [127.0.0.1]) by insomnia.benzedrine.cx (8.13.4/8.13.4) with ESMTP id k6B6MTql008639 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Tue, 11 Jul 2006 08:22:30 +0200 (MEST) Received: (from dhartmei@localhost) by insomnia.benzedrine.cx (8.13.4/8.12.10/Submit) id k6B6MTn5002100; Tue, 11 Jul 2006 08:22:29 +0200 (MEST) Date: Tue, 11 Jul 2006 08:22:29 +0200 From: Daniel Hartmeier To: Michael Vince Message-ID: <20060711062229.GG27312@insomnia.benzedrine.cx> References: <44B339D6.7090401@thebeastie.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <44B339D6.7090401@thebeastie.org> User-Agent: Mutt/1.5.10i Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jul 2006 06:22:57 -0000 On Tue, Jul 11, 2006 at 03:40:38PM +1000, Michael Vince wrote: > That still doesn't really answer my question and I also am looking for a > flags example of what would guarantee to provide the desired behavior. If you don't specify a 'flags' option, the rule will match any flags combination. Don't use 'modulate state' in this case. If you remove the state, and create a second state from another packet of the ongoing connection, 'modulate state' will pick a random (most certainly different) sequence number modulator, and the connection will immediately stall when the endpoints see the new and completely out-of-bounds sequence numbers. You can only use 'modulate state' when you create state on the initial SYN of a connection ('flags S/SA' is recommended there) and preserve that state entry for the duration of the connection. If you lose the state entry, the connection will stall. So, use 'keep state' instead. But that won't work, in general, either. Nowadays many hosts enable TCP window scaling and use >0 scaling factors. For pf to support that properly, it must also create state on the initial SYN. Creating a state from any packet later than the SYN will eventually stall the connection. If you know TCP window scaling isn't used, you can create state on any packet, but in general you should use 'flags S/SA' on state creating rules. In short, don't lightly flush your states. There's no reason to flush states in normal operation (like, when reloading the ruleset). If you don't want to have to reestablish connections when the firewall must be rebooted, there's pfsync to synchronize states to a backup firewall and carp to do automatic failover. > So your saying that to stop packets going *out* its more "natural" to > type up a *block in* firewall rule to achieve the desired result, I > think its is a hard point of view to argue, and this was something that > was never needed with IPFilter and is probably one of its better > remaining features over PF. Maybe you can argue what seems more intuitive to you, but technically, it's more straight-forward to block packets as early as possible (for forwarded packets that is on the input path). What's the point of allowing a packet in on the internal interface, have the stack do a route lookup and try forward the packet out through the external interface, just to then block it there? Waste of CPU cycles and network buffers. If for some technical reasons you want to filter on the external interface based on source address lost due to NAT translation, you can try tagging on the internal interface and distinguish based on tags on the external interface. But if you'd just prefer to not have "translation occur before filtering", I guess you're way too late to suggest that. It was a deliberate design choice, and people grew to appreciate and rely on this order. Daniel