PF slowing down file copies
fbsd06 at mlists.homeunix.com
Thu Feb 22 15:52:28 UTC 2007
On Thu, 22 Feb 2007 17:04:18 +0200
Giorgos Keramidas <keramida at ceid.upatras.gr> wrote:
> On 2007-02-22 14:30, RW <fbsd06 at mlists.homeunix.com> wrote:
> >On Wed, 21 Feb 2007 19:38:39 +0100
> >J65nko <j65nko at gmail.com> wrote:
> >> For keeping state on TCP connections you should only create state
> >> on the first packet of the 3 way TCP handshake. Using "flags S/SA"
> >> will ensure this. This will prevent problems with TCP windows
> >> scaling..
> > Why? Creating a state entry causes subsequent packets, in the same
> > tcp connection, to bypass the rules altogether.
> Because a state entry is a rule by itself. A special 'rule', but
> still a rule. As such, each state-table entry requires a finite
> amount of resources. Conserving resources, whenever possible, is a
> good idea.
> Creating 10 packets for a connection whose 'traffic' requires 10 TCP
> segments to be transmitted, and 9000 state entries for a TCP
> connection whose data payload needs 9000 segments to be transmitted
> is kind of silly. Especially since it is entirely legal and easy to
> do the same thing with only 2 state entries (one for each connection).
The way PF works is that it first checks if there is a state entry
matching the packet's address, port and protocol , if there is the
state entry is used to determine what is done with the packet. Only if
there is no matching entry is the script used instead. As I already
said "Creating a state entry causes subsequent packets, in the same tcp
connection, to bypass the rules altogether".
The point of testing for s/sa is to avoid creating long-lived state
entries for illegal or out-of-sequence packets. The state created by
s/sa has a very short lifetime. This conserves resources and protects
against some DOS attacks.
More information about the freebsd-questions