From owner-freebsd-bugs@FreeBSD.ORG Thu Oct 28 03:40:34 2004 Return-Path: Delivered-To: freebsd-bugs@hub.freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9F86616A4CE for ; Thu, 28 Oct 2004 03:40:34 +0000 (GMT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 706B543D4C for ; Thu, 28 Oct 2004 03:40:34 +0000 (GMT) (envelope-from gnats@FreeBSD.org) Received: from freefall.freebsd.org (gnats@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.11/8.12.11) with ESMTP id i9S3eYx8062685 for ; Thu, 28 Oct 2004 03:40:34 GMT (envelope-from gnats@freefall.freebsd.org) Received: (from gnats@localhost) by freefall.freebsd.org (8.12.11/8.12.11/Submit) id i9S3eYGw062684; Thu, 28 Oct 2004 03:40:34 GMT (envelope-from gnats) Date: Thu, 28 Oct 2004 03:40:34 GMT Message-Id: <200410280340.i9S3eYGw062684@freefall.freebsd.org> To: freebsd-bugs@FreeBSD.org From: Giorgos Keramidas Subject: Re: kern/73202: IPF causing major tcp problems with 3rd party apps (apache, exim etc) X-BeenThere: freebsd-bugs@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: Giorgos Keramidas List-Id: Bug reports List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Oct 2004 03:40:34 -0000 The following reply was made to PR kern/73202; it has been noted by GNATS. From: Giorgos Keramidas To: David Haworth Cc: bug-followup@freebsd.org Subject: Re: kern/73202: IPF causing major tcp problems with 3rd party apps (apache, exim etc) Date: Thu, 28 Oct 2004 06:34:57 +0300 On 2004-10-27 22:20, David Haworth wrote: > You're quite right, I should have pointed out that the firewall ruleset was > completely unchanged from the 5.1 config. I don't really want to post my > firewall config to a public forum so I'll enclose a suitably edited version. > > this config worked fine with 5.1 and caused no problems. I think you have problems because of the unmatched `in' rules for some services that you make visible from outside. I call these rules `unmatched' because there is no matching `out' rule to let the replies get out too: > block in log on vr0 > block in log quick all with ipopts > block in quick all with frag > block in quick all with short > block in quick on vr0 proto tcp from any to any port = 135 > [...] > pass in quick on vr0 proto tcp from any to $local_ip1 port = smtp > pass in quick on vr0 proto tcp from any to $local_ip1 port = http > pass in quick on vr0 proto tcp from any to $local_ip2 port = http > [...] This means that incoming packets for these ports are unconditionally allowed to pass through. Nothing is said about outgoing packets, so the default policy is assumed. You haven't set the default `out' policy for interface vr0 in your ruleset so this can be either `pass' (the default) or `block' (if you have compiled your kernel with IPFILTER_DEFAULT_BLOCK). A few rules further down you have: > pass in quick on vr0 proto tcp from any to any port = 22 flags S keep state > pass out quick on vr0 proto tcp/udp from any to any keep state keep frags Your problems are very probably caused by this mixing of stateless and stateful rules. Combined with the fact that you don't cover *all* possible cases of packets, this can be tricky. Try converting the stateless rules to stateful, i.e. replace this: > pass in quick on vr0 proto tcp from any to $local_ip1 port = smtp > pass in quick on vr0 proto tcp from any to $local_ip1 port = http > pass in quick on vr0 proto tcp from any to $local_ip2 port = http with something like this: > pass in quick on vr0 proto tcp from any to $local_ip1 port = smtp keep state > pass in quick on vr0 proto tcp from any to $local_ip1 port = http keep state > pass in quick on vr0 proto tcp from any to $local_ip2 port = http keep state Let us know if that fixes the problems you're seeing. Regards, Giorgos.