From owner-freebsd-pf@FreeBSD.ORG Wed Apr 2 20:33:57 2008 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 17895106566C for ; Wed, 2 Apr 2008 20:33:57 +0000 (UTC) (envelope-from m.pagulayan@auckland.ac.nz) Received: from mailhost.auckland.ac.nz (moe.its.auckland.ac.nz [130.216.12.35]) by mx1.freebsd.org (Postfix) with ESMTP id A7D9A8FC13 for ; Wed, 2 Apr 2008 20:33:56 +0000 (UTC) (envelope-from m.pagulayan@auckland.ac.nz) Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 3ACCB48070B; Thu, 3 Apr 2008 09:33:55 +1300 (NZDT) X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (moe.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THr+O3UaYFlM; Thu, 3 Apr 2008 09:33:54 +1300 (NZDT) Received: from UXCHANGE2.UoA.auckland.ac.nz (uxcn2.itss.auckland.ac.nz [130.216.190.119]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 984A64806EC; Thu, 3 Apr 2008 09:33:53 +1300 (NZDT) Received: from UXCHANGE1.UoA.auckland.ac.nz ([130.216.190.118]) by UXCHANGE2.UoA.auckland.ac.nz with Microsoft SMTPSVC(6.0.3790.1830); Thu, 3 Apr 2008 09:33:30 +1300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Thu, 3 Apr 2008 09:33:28 +1300 Message-ID: In-Reply-To: <684548.87924.qm@web57414.mail.re1.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: PF and State Table Thread-Index: AciUqhzCzqq4/JzkTs67UBTfXdfdYAAVms5A References: <684548.87924.qm@web57414.mail.re1.yahoo.com> From: "Mark Pagulayan" To: "Diego Salvador" , X-OriginalArrivalTime: 02 Apr 2008 20:33:30.0644 (UTC) FILETIME=[D03FCD40:01C89500] Cc: freebsd-pf@freebsd.org Subject: RE: PF and State Table X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2008 20:33:57 -0000 Hi,=20 What pf version are you using? Correct me if I am wrong guys, on PF4.1 which a the release version of pf on freebsd 7.0 when you specify keep state the flag S/A is implied?=20 Cheers,=20 Mark -----Original Message----- From: owner-freebsd-pf@freebsd.org [mailto:owner-freebsd-pf@freebsd.org] On Behalf Of Diego Salvador Sent: Wednesday, 2 April 2008 10:54 p.m. To: fox@verio.net Cc: freebsd-pf@freebsd.org Subject: Re: PF and State Table Sir David, So you mean to say that it is really required for pf rules to specify TCP=20 flags when used with keep state? Because this seems to relate my=20 previous problem with PF firewall that will cause a problem in browsing Google and Youtube web sites with Windows Vista nodes behind PF. Example rules for the node are pass in on $ext_if inet from any to 192.168.100.1=20 pass out on $ext_if inet from 192.168.100.1 to any keep state=20 where 192.168.100.1 is a Windows Vista node behind a FreeBSD PF firewall. As you can see the above rules, I didn't specify any specific protocols like TCP, UDP=20 and ICMP so TCP here just use the "keep state" option without flags. Google and=20 Youtube sites seem to not continue displaying web pages but I can see that the=20 connection were established with the Windows Vista node with Google and Youtube=20 sites. Yes, that's what I'm looking for, the file where I can analyze PF state table=20 in the source code. Thanks, Diego Salvador > > This is somewhat risky, because you really don't want to waste a state > entry on something that's half-way in the middle of a TCP session > (well, I suppose you could, but it seems insecure. It's more than just insecure; it can cause breakage of TCP connections, especially in a world where RFC 1323 is commonplace (i.e. today's world). If PF starts tracking state from the middle of a connection, it has missed out on discovering what TCP window scaling factors are in use.=20 If there happens to be no scaling in use, it works fine, but if a scale factor is being applied, PF will not track the state correctly, and the connection will stall out. > > What file in PF on FreeBSD kernel does state table structure is > > located? >=20 > I don't understand this question. I think the question is asking for details on how PF state is stored in memory. I found a very nice struct pf_state in /usr/include/net/pfvar.h. =20 --------------------------------- Tired of spam? Yahoo! Mail has the best spam protection around http://ph.mail.yahoo.com _______________________________________________ freebsd-pf@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-pf To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org"