[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: PF slowing down file copies
- To: RW <fbsd06_(_at_)_mlists_(_dot_)_homeunix_(_dot_)_com>
- Subject: Re: PF slowing down file copies
- From: Giorgos Keramidas <keramida_(_at_)_ceid_(_dot_)_upatras_(_dot_)_gr>
- Date: Thu, 22 Feb 2007 23:40:01 +0200
- Cc: freebsd-questions_(_at_)_freebsd_(_dot_)_org
On 2007-02-22 15:52, RW <fbsd06_(_at_)_mlists_(_dot_)_homeunix_(_dot_)_com> wrote:
>On Thu, 22 Feb 2007 17:04:18 +0200
>Giorgos Keramidas <keramida_(_at_)_ceid_(_dot_)_upatras_(_dot_)_gr> wrote:
>>On 2007-02-22 14:30, RW <fbsd06_(_at_)_mlists_(_dot_)_homeunix_(_dot_)_com> wrote:
>>>On Wed, 21 Feb 2007 19:38:39 +0100
>>>J65nko <j65nko_(_at_)_gmail_(_dot_)_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
>>> 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'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 :)
freebsd-questions_(_at_)_freebsd_(_dot_)_org mailing list
To unsubscribe, send any mail to "freebsd-questions-unsubscribe_(_at_)_freebsd_(_dot_)_org"