From owner-freebsd-current@FreeBSD.ORG Mon Apr 15 10:57:18 2013 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.FreeBSD.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 72ECAFC6 for ; Mon, 15 Apr 2013 10:57:18 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) by mx1.freebsd.org (Postfix) with ESMTP id 2F01E611 for ; Mon, 15 Apr 2013 10:57:18 +0000 (UTC) Received: from slw by zxy.spb.ru with local (Exim 4.69 (FreeBSD)) (envelope-from ) id 1URh5u-0005tb-RW for freebsd-current@freebsd.org; Mon, 15 Apr 2013 14:57:06 +0400 Date: Mon, 15 Apr 2013 14:57:06 +0400 From: Slawa Olhovchenkov To: freebsd-current@freebsd.org Subject: Re: ipfilter(4) needs maintainer Message-ID: <20130415105706.GB21132@zxy.spb.ru> References: <20130414160648.GD96431@in-addr.com> <36562.1365960622.5652758659450863616@ffe10.ukr.net> <201304150025.07337.Mark.Martinec+freebsd@ijs.si> <951943801.20130415141536@serebryakov.spb.ru> <195468703.20130415143237@serebryakov.spb.ru> <621849003.20130415144428@serebryakov.spb.ru> <66408799.20130415145023@serebryakov.spb.ru> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <66408799.20130415145023@serebryakov.spb.ru> User-Agent: Mutt/1.5.21 (2010-09-15) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 10:57:18 -0000 On Mon, Apr 15, 2013 at 02:50:23PM +0400, Lev Serebryakov wrote: > KP> I'm however talking about an ftp client behind a very restrictive > KP> firewall making an IPv6 connection an ftp server that uses passive > KP> mode data ports that can't be known in advance. > Same solution -- inspection of connections to 21 port, without any > address translation. And if FTP server uses non-standard control > port, yes, here is a problem, but it cannot be solved with NAT too > (or your NAT/firewall should expect each and every connection for FTP > commands, which is heavy and error-prone task). Not heavy. But error-prone, yes.