From owner-freebsd-pf@FreeBSD.ORG Fri Jun 15 07:11:47 2007 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 26D4C16A400 for ; Fri, 15 Jun 2007 07:11:47 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from frontmail.ipactive.de (frontmail.maindns.de [85.214.95.103]) by mx1.freebsd.org (Postfix) with ESMTP id B289A13C45B for ; Fri, 15 Jun 2007 07:11:46 +0000 (UTC) (envelope-from volker@vwsoft.com) Received: from mail.vtec.ipme.de (Q7cc2.q.ppp-pool.de [89.53.124.194]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by frontmail.ipactive.de (Postfix) with ESMTP id 009EB128844 for ; Fri, 15 Jun 2007 09:11:39 +0200 (CEST) Received: from cesar.sz.vwsoft.com (cesar.sz.vwsoft.com [192.168.16.3]) by mail.vtec.ipme.de (Postfix) with ESMTP id D22433F51A; Fri, 15 Jun 2007 09:10:35 +0200 (CEST) Message-ID: <46723B71.1080404@vwsoft.com> Date: Fri, 15 Jun 2007 09:10:41 +0200 From: Volker User-Agent: Thunderbird 2.0.0.0 (X11/20070528) MIME-Version: 1.0 To: Vlad GURDIGA References: In-Reply-To: X-Enigmail-Version: 0.95.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-VWSoft-MailScanner: Found to be clean X-MailScanner-From: volker@vwsoft.com X-ipactive-MailScanner-Information: Please contact the ISP for more information X-ipactive-MailScanner: Found to be clean X-ipactive-MailScanner-From: volker@vwsoft.com Cc: freebsd-pf@freebsd.org Subject: Re: pf(4) + fetch(1) + http://ftp.gnu.org 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: Fri, 15 Jun 2007 07:11:47 -0000 On 06/15/07 08:24, Vlad GURDIGA wrote: > Hello, > > There is one strange thing going on with this combination. I saw this > many times by now: when fetch(1) is trying to download something from > http://ftp.gnu.org, it is hanging after a very small amount of data; > sometimes on 0%. After disabling pf(4), fetch(1) is not hanging any > more, so I guess that the problem is somewhere in my pf.conf. Here is > it: > > ---- pf.conf -- begin --- > ext_if = "em0" > icmp_types="echoreq" > > # don't filter on the loopback interface > set skip on lo0 > set block-policy return > > scrub all no-df random-id reassemble tcp > > # setup a default deny policy > block all > > # activate spoofing protection for the internal interface. > antispoof quick for lo0 inet > > # pass tcp, udp, and icmp out on the external (Internet) interface. > # keep state on udp and icmp and modulate state on tcp. > pass in on $ext_if proto tcp from any to $ext_if port 65522 keep state > > pass in inet proto icmp all icmp-type $icmp_types keep state > pass out on $ext_if proto tcp all modulate state flags S/SA > pass out on $ext_if proto {udp, icmp} all keep state > ---- pf.conf -- end --- > > Any idea what's wrong here? Vlad, if we're out of ideas, there would be something wrong... ;) My first try is to replace your 'pass out on $ext_if ... modulate state ...' by 'keep state'. modulate state is more of use for incoming connections as you don't want half open connections to your services. HTH Volker