From owner-freebsd-pf@FreeBSD.ORG Wed May 14 12:40:46 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 53F401065685 for ; Wed, 14 May 2008 12:40:46 +0000 (UTC) (envelope-from freebsd@violetlan.net) Received: from mail.violetlan.net (host-80-81-242-11.violetlan.net [80.81.242.11]) by mx1.freebsd.org (Postfix) with ESMTP id 17C848FC1F for ; Wed, 14 May 2008 12:40:46 +0000 (UTC) (envelope-from freebsd@violetlan.net) Received: from mail.violetlan.net (localhost [127.0.0.1]) by mail.violetlan.net (Postfix) with ESMTP id A04F111460 for ; Wed, 14 May 2008 13:38:17 +0100 (BST) Received: from www.violetlan.net (mbali.violetlan.net [10.0.100.150]) by mail.violetlan.net (Postfix) with ESMTP id 8072011464 for ; Wed, 14 May 2008 13:38:17 +0100 (BST) Received: from 217.41.34.61 (SquirrelMail authenticated user freebsd@violetlan.net) by www.violetlan.net with HTTP; Wed, 14 May 2008 13:36:18 +0100 (BST) Message-ID: <63902.217.41.34.61.1210768578.squirrel@www.violetlan.net> Date: Wed, 14 May 2008 13:36:18 +0100 (BST) From: "Reinhold" To: freebsd-pf@freebsd.org User-Agent: SquirrelMail/1.5.1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: ClamAV using ClamSMTP Subject: Re: a few problems with pf 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, 14 May 2008 12:40:46 -0000 On Wed, May 14, 2008 09:39, Jeremy Chadwick wrote: > On Wed, May 14, 2008 at 09:30:17AM +0100, Reinhold wrote: > >> I'm have a few problems with pf on my FreeBSD 7 STABLE systems, I have >> two running 7 and 4 running 6.3 and the problems are only on my 7 >> systems. >> >> The first problem is that I'm plagued by bad hdr length on both my 7 >> systems > > When using tcpdump with pflog, you'll need to specify a large frame size > to analyse/snoop; the default size is too small. Use -s 1024 to address > that. > Here is the results using -s 1024 2008-05-14 11:09:02.375144 rule 5/0(match): block in on ng0: 71.226.2.26.63696 > 217.41.34.61.64166: S 2876080469:2876080469(0) win 8192 2008-05-14 11:09:02.379780 rule 6/0(match): block in on ng0: 71.226.2.26.37654 > 217.41.34.61.64166: UDP, length 20 2008-05-14 11:09:03.019599 rule 5/0(match): block in on ng0: 71.226.2.26.63696 > 217.41.34.61.64166: S 2876080469:2876080469(0) win 8192 2008-05-14 11:09:03.672268 rule 5/0(match): block in on ng0: 71.226.2.26.63696 > 217.41.34.61.64166: S 2876080469:2876080469(0) win 8192 What I've also noticed is that in pf I have this rule pass in log quick on $ext_if1 reply-to ($ext_if1 $ext_gw1) proto tcp from any to { 192.168.1.2 } port = 22 keep state (max 1024, max-src-conn 15, max-src-conn-rate 2/1, overload flush global) When I'm getting the bad header thingy this rule doesn't work properly. It let all the traffic trough but it never blocks the bad guys.