From owner-freebsd-net@FreeBSD.ORG Tue Apr 22 01:35:36 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 E671737B401 for ; Tue, 22 Apr 2003 01:35:35 -0700 (PDT) Received: from mailout.informatik.tu-muenchen.de (mailout.informatik.tu-muenchen.de [131.159.0.5]) by mx1.FreeBSD.org (Postfix) with ESMTP id 8120543F75 for ; Tue, 22 Apr 2003 01:35:34 -0700 (PDT) (envelope-from langd@informatik.tu-muenchen.de) Received: from mailrelay1.informatik.tu-muenchen.de (mailrelay1.informatik.tu-muenchen.de [131.159.254.5]) by mailout.informatik.tu-muenchen.de (Postfix) with ESMTP id BDA3F617C; Tue, 22 Apr 2003 10:35:33 +0200 (MEST) Received: from atrbg11.informatik.tu-muenchen.de (atrbg11.informatik.tu-muenchen.de [131.159.42.129]) by mailrelay1.informatik.tu-muenchen.de (Postfix) with ESMTP id A3681794D; Tue, 22 Apr 2003 10:35:33 +0200 (MEST) Received: by atrbg11.informatik.tu-muenchen.de (Postfix, from userid 20455) id 2F7E613B5D; Tue, 22 Apr 2003 10:35:33 +0200 (CEST) Date: Tue, 22 Apr 2003 10:35:32 +0200 From: Daniel Lang To: Martin Stiemerling Message-ID: <20030422083532.GB49848@atrbg11.informatik.tu-muenchen.de> References: <20030417072027.GA38782@atrbg11.informatik.tu-muenchen.de> <3E9E6D34.5020100@ccrle.nec.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3E9E6D34.5020100@ccrle.nec.de> X-Geek: GCS/CC d-- s: a- C++$ UBS++++$ P+++$ L- E-(---) W+++(--) N++ o K w--- O? M? V? PS+(++) PE--(+) Y+ PGP+ t++ 5+++ X R+(-) tv+ b+ DI++ D++ G++ e+++ h---(-) r++>+++ y+ User-Agent: Mutt/1.5.1i 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 08:35:36 -0000 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 -- IRCnet: Mr-Spock - "I hear that, if you play the WindowsXP CD backwards, you get a Satanic message!" - "That's nothing. If you play it forward, it installs WindowsXP!" Daniel Lang * dl@leo.org * +49 89 289 18532 * http://www.leo.org/~dl/