Date: Tue, 11 Jul 2006 08:22:29 +0200 From: Daniel Hartmeier <daniel@benzedrine.cx> To: Michael Vince <mv@thebeastie.org> Cc: freebsd-pf@freebsd.org Subject: Re: PF firewall rules Message-ID: <20060711062229.GG27312@insomnia.benzedrine.cx> In-Reply-To: <44B339D6.7090401@thebeastie.org> References: <D5972F49810A69449A9EA72A4B360DC2D0A38F@e1.universe.dart.spb> <44B339D6.7090401@thebeastie.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060711062229.GG27312>