Date: Thu, 22 Feb 2007 23:40:01 +0200 From: Giorgos Keramidas <keramida@ceid.upatras.gr> To: RW <fbsd06@mlists.homeunix.com> Cc: freebsd-questions@freebsd.org Subject: Re: PF slowing down file copies Message-ID: <20070222214001.GC1781@kobe.laptop> In-Reply-To: <20070222155223.0dd15975@gumby.homeunix.com> References: <200702202021.55723.pablo.fernandez@rs.com.ar> <19861fba0702211038p3144271ey1e30cf67311678ef@mail.gmail.com> <20070222143030.0b858e86@gumby.homeunix.com> <20070222150418.GA3298@kobe.laptop> <20070222155223.0dd15975@gumby.homeunix.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2007-02-22 15:52, RW <fbsd06@mlists.homeunix.com> wrote: >On Thu, 22 Feb 2007 17:04:18 +0200 >Giorgos Keramidas <keramida@ceid.upatras.gr> wrote: >>On 2007-02-22 14:30, RW <fbsd06@mlists.homeunix.com> wrote: >>>On Wed, 21 Feb 2007 19:38:39 +0100 >>>J65nko <j65nko@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. I see. I've recently discovered that IPFilter v4.0.2 on Solaris 10 had a bug in the state expiry code. States for packets without S/SA expire after 10 days, instead of a few seconds like the S/SA states. I haven't verified that this doesn't apply to PF, but since PF is a very different firewall I'll extract my foot from my mouth and go read the source now :)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20070222214001.GC1781>