On Thu, 22 Feb 2007 17:04:18 +0200 Giorgos Keramidas <[EMAIL PROTECTED]> wrote:
> On 2007-02-22 14:30, RW <[EMAIL PROTECTED]> wrote: > >On Wed, 21 Feb 2007 19:38:39 +0100 > >J65nko <[EMAIL PROTECTED]> 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. _______________________________________________ email@example.com mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"