From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 02:18:42 2003 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B6A1C37B401 for ; Tue, 22 Apr 2003 02:18:42 -0700 (PDT) Received: from tokyo.ccrle.nec.de (tokyo.ccrle.nec.de [195.37.70.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 3795243FCB for ; Tue, 22 Apr 2003 02:18:41 -0700 (PDT) (envelope-from Martin.Stiemerling@ccrle.nec.de) Received: from venus.office (venus.office [10.1.1.11]) by tokyo.ccrle.nec.de (8.12.9/8.12.8) with ESMTP id h3M9IVVI039321; Tue, 22 Apr 2003 11:18:32 +0200 (CEST) Received: from ccrle.nec.de (n-stiemerling.office [10.1.1.109]) by venus.office (Postfix on SuSE Linux eMail Server 3.0) with ESMTP id 24FB290A27; Tue, 22 Apr 2003 11:13:23 +0200 (CEST) Message-ID: <3EA508EB.5020906@ccrle.nec.de> Date: Tue, 22 Apr 2003 11:18:35 +0200 From: Martin Stiemerling Organization: NEC -- Network Labs Europe User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc3) Gecko/20020619 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Lang References: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> <3E9E6D34.5020100@ccrle.nec.de> <20030422083532.GB49848@atrbg11.informatik.tu-muenchen.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-net@freebsd.org Subject: Re: IPfilter changes? X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Apr 2003 09:18:43 -0000 Hi Daniel, the stuff below looks ok so far, i.e. it should work. Perhaps you can check with 'ipfstat -hio' (it shows the hit counts per rule) where the intial TCP packet from your host 131.159.72.12 is matched against a rule, especially this rule: > pass in quick from 131.159.72.12/32 to any If this doesn't help try to replace the state rule with this and check whether this rule has been hit at all. > pass out quick proto tcp/udp from any to any keep state keep frags NEW > pass out quick proto tcp from any to any flags S keep state keep frags IP Filter has neither changed rule processing nor a new keyword. Cheers Martin Daniel Lang wrote: > Hi Folks, > > I've investigated further and come to the conclusion, that > the ipfilter on my box does no longer keep the state all. > It doesn't work any more for both TCP und UDP. > > I tried to initiate a ssh connection to a host, that is > not explicitly permitted, and I can see that its replies > are blocked by ipfilter: > [..] > Apr 22 10:11:22 atleo3 ipmon[60]: 10:11:21.773527 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN > Apr 22 10:11:28 atleo3 ipmon[60]: 10:11:27.973741 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN > Apr 22 10:11:29 atleo3 ipmon[60]: 10:11:29.593264 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 44 -AS IN > Apr 22 10:11:40 atleo3 ipmon[60]: 10:11:40.174349 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN > Apr 22 10:11:56 atleo3 ipmon[60]: 10:11:56.593091 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 44 -AS IN > Apr 22 10:12:04 atleo3 ipmon[60]: 10:12:04.374875 xl0 @0:7 b 131.159.4.145,22 -> 131.159.72.12,1066 PR tcp len 20 40 -A IN > [..] > > Maybe the ruleset processing order has changed? Here are relevant > rules, as used in the kernel. I use ipfstat -oi to show you my rules: > [..] > > pass out quick on lo0 from any to any > pass out quick proto icmp from any to any > pass out quick proto tcp/udp from any to any keep state keep frags > > block in from any to any > pass in quick on lo0 from any to any > pass in quick from 131.159.72.12/32 to any > block in quick proto tcp from any to any with short > block in log level local7.notice from any to any > block in log level local7.notice proto tcp from any to any > ^^^^^^^^^^^^^^^^^^^ > This is the rule, that blocks the packet according to the log (@7). > [..] > block return-rst in log level local7.notice quick proto tcp from any to any port = 1080 > block return-rst in log level local7.notice quick proto tcp from any to any port = 3128 > block return-rst in log level local7.notice quick proto tcp from any to any port = 8080 > block in proto udp from any to any > pass in quick proto icmp from any to any > block in quick from any to 224.0.0.0/8 > [ rules with special host exceptions omitted ] > > Maybe there is now a special keyword required to make a states > overrule blocking rules? > > If I display current state in 'top' mode, and try to initiate a > connection, the state does not get added! Only states of connections, > that can be established due to explicitly allowed rules seem to get added. > > So that seems to be the problem, that somehow a connection is only > added to the state tables, once it is established? That would > explain why it breaks now, but I'm not sure, if I'm just doing something > wrong? > > Any explanations appreciated. > > Best regards, > Daniel -- Martin Stiemerling NEC Europe Ltd. -- Network Laboratories Stiemerling@ccrle.nec.de IPv4: http://www.ccrle.nec.de IPv6: http://www.ipv6.ccrle.nec.de