From owner-freebsd-questions Thu Aug 23 16:23:15 2001 Delivered-To: freebsd-questions@freebsd.org Received: from zoe.sbs-online.com (adsl-136-146.wanadoo.be [213.177.136.146]) by hub.freebsd.org (Postfix) with ESMTP id D3F8E37B409 for ; Thu, 23 Aug 2001 16:23:05 -0700 (PDT) (envelope-from fs.mail@wanadoo.be) Received: from scuba.sbs-online.com (scuba.sbs-online.com [192.168.1.1]) by zoe.sbs-online.com (Postfix) with ESMTP id 7848049AC8; Fri, 24 Aug 2001 01:20:22 +0200 (CEST) Date: Fri, 24 Aug 2001 01:24:34 +0200 From: Frank Sonnemans Reply-To: fs.mail@wanadoo.be To: David Kelly Cc: freebsd-questions@FreeBSD.ORG Subject: Re: Fetching ports from behind a firewall Message-ID: <49140000.998609074@localhost> X-Mailer: Mulberry/2.0.6 (Linux/x86) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Thanks for the explanation now it is clear what happens. I let out the PASV request on the ftp port, but I don't use NAT on this box. Since I don't allow outgoing connections (except on some ports) the client is unable to connect to the port address returned by the ftp server. I'll give the punch_fw option a try. If it doesn't work I can allways switch back to ipfilter which did work for me. Thanks again, Frank --On Wednesday, August 22, 2001 22:02:48 -0500 David Kelly wrote: > Frank Sonnemans writes: >> >> I enabled ipfw on my machine and am no longer able to compile ports >> without disabling the firewall. My firewall allows outgoing ftp >> connections (keep state) which should make passive ftp connections >> possible. >> >> Fetching the source code still fails, even though the appropriate >> environment variable to use passive ftp has been set (from man 3 fetch). >> >> What am I missing? > > It matters a lot as to how you wrote your IPFW rules as one of those is > blocking the FTP data connection. Experiment with "deny log" and study > the contents of /var/log/security to find out where your ftp is failing. > > One way to get out with ftp is to allow all outgoing TCP connections. > Otherwise the only way I've found is to add a divert rule and natd. > Within natd you need something like this for a config file: > > log_facility security > log_denied yes > dynamic yes > use_sockets yes > same_ports yes > punch_fw 2850:48 > > The key is, "punch_fw" which is a feature of natd that knows what an ftp > session looks like and will sniff it and in this example will write up > to 48 ipfw rules starting at rule 2850 to let sessions thru. When a > session closes natd deletes the rule by number so its important it > doesn't write rules with the same number as any you already have. > > ipfw lets you have multiple rules on a number, but delete removes all > on the specified number. > > ftp(1) has a nice description of what is going on: > > passive Toggle passive mode. If passive mode is turned on > (default is off), the ftp client will send a PASV command for all > data connections instead of the usual PORT command. The > PASV com- mand requests that the remote server open a > port for the data connection and return the address of > that port. The remote server listens on that port and > the client connects to it. When using the more > traditional PORT command, the client lis- tens on a port > and sends that address to the remote server, who > connects back to it. Passive mode is useful when using > ftp through a gateway router or host that controls the > direc- tionality of traffic. > > So at the very least to make natd work you need an ipfw rule allowing > connections to "any 21" so punch_fw can write the return rule. If > punch_fw is not working then you can connect to the ftp server but not > get a listing of files, or be able to transfer files. > > > -- > David Kelly N4HHE, dkelly@hiwaay.net > ===================================================================== > The human mind ordinarily operates at only ten percent of its > capacity -- the rest is overhead for the operating system. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-questions" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message