From owner-freebsd-pf@FreeBSD.ORG Tue Jul 11 08:17:05 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 684EB16A4DA for ; Tue, 11 Jul 2006 08:17:05 +0000 (UTC) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (ns1.ecoms.com [207.44.130.137]) by mx1.FreeBSD.org (Postfix) with ESMTP id E2CA343D4C for ; Tue, 11 Jul 2006 08:17:04 +0000 (GMT) (envelope-from mv@thebeastie.org) Received: from p4.roq.com (localhost.roq.com [127.0.0.1]) by p4.roq.com (Postfix) with ESMTP id 7426B4CE05 for ; Tue, 11 Jul 2006 08:17:09 +0000 (GMT) Received: from vaulte.jumbuck.com (ppp166-27.static.internode.on.net [150.101.166.27]) by p4.roq.com (Postfix) with ESMTP id 73AEE4CDFF for ; Tue, 11 Jul 2006 08:17:08 +0000 (GMT) Received: from vaulte.jumbuck.com (localhost [127.0.0.1]) by vaulte.jumbuck.com (Postfix) with ESMTP id DC02A8A06F; Tue, 11 Jul 2006 18:17:01 +1000 (EST) Received: from [192.168.46.102] (unknown [192.168.46.250]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by vaulte.jumbuck.com (Postfix) with ESMTP id CADAE8A06D; Tue, 11 Jul 2006 18:17:01 +1000 (EST) Message-ID: <44B35E7D.5010107@thebeastie.org> Date: Tue, 11 Jul 2006 18:17:01 +1000 From: Michael Vince User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.7.12) Gecko/20060404 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Hartmeier References: <44B339D6.7090401@thebeastie.org> <20060711062229.GG27312@insomnia.benzedrine.cx> In-Reply-To: <20060711062229.GG27312@insomnia.benzedrine.cx> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Virus-Scanned: ClamAV using ClamSMTP 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 08:17:05 -0000 Daniel Hartmeier wrote: >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 ultimately what your saying is PF is too clever now and can never be simplified like UDP state modes for single line firewall rules using rough careless flags options on a firewall rules where everything is just going out keep state and otherwise blocking all in. This is fair enough, I just had to ask. To me it just seemed a bit unreasonable to bit so stricted about TCP while being so lean and easy going and in one sense clever with UDP and ICMP. While the inherited TCP flags give you the ability to be more strict about it all I just would of thought if I want to have a easy/non strict going firewall I would be able to configure it like that with no problems. While I don't understand the TCP protocol as well as you guys, I do tent to see as protocol racism, making it all easy for the white UDP people and being tough on the TCP black people (if it was a firewall/country of largely white population in the 50s) > > >>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. > > Darn, I had wondered about this for a bit now, so all IPFilter users have to readapt their mind frame for PF, I don't know why but I have had a little bit of a hard time with this, I guess the reasons I liked IPFilter and also PF has been because its its very english language like syntax and mind frame. One way to kind of add onto the syntax but still keep the "out" word in there would be to place the keyword "kernel" to help let the user know which direction the packet is going in and out of the internal interface. I don't know if it is the best solution but I do get to keep my "out" word even if its a bit selfish. block out quick on $int_if kernel proto { tcp, udp, icmp } from 192.168.1.17 to any Yes, one of the issues I had against blocking so early on the internal interface is it ruins the ability to run services on internal NAT ip servers using RDR for internal IPs but providing a single IP to all users behind the firewall and for those over the Internet. If I want to block some IPs from reaching the Internet but still be able to use the web server behind NAT firewall I have to allow extra firewall rules for those IPs before they hit the firewall rule above that blocks everything going out on the internal interface. Considering the above firewall rule depending on how it was implemented might not work another syntax/feature that could allow packets going in to the external interface from the kernel side of things block in quick on $ext_if kernel proto { tcp, udp, icmp } from 192.168.1.17 to any While I am back to square 1 with the "in" statement it would still me from having to have special rules allowing stuff back in to internal redirected services. Mike