From owner-freebsd-ipfw@FreeBSD.ORG Mon Jan 16 19:32:25 2012 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 49A49106564A for ; Mon, 16 Jan 2012 19:32:25 +0000 (UTC) (envelope-from fjwcash@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id 0118E8FC13 for ; Mon, 16 Jan 2012 19:32:24 +0000 (UTC) Received: by vbbey12 with SMTP id ey12so893302vbb.13 for ; Mon, 16 Jan 2012 11:32:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=tn9niggEp/CcvrZ1fuDkrQRGXsUeScbK83yxtzpbQ+c=; b=nP9pz9VhW4ajMkQLQTxcY/cUGsCJL/SUmcxTDunXRp4B6NHJ0/Xr+3E7LGwjFwbFCn reeTzchSBFIaZa3w0bZX2zJiZKwnnEE9VkyiO0HR6FLgzoqNLNtp8qaOGf4YbcOXd1Jx qHF5LkwfinT4e4by+5Dtb9pvGXPk+Lyji0BqM= MIME-Version: 1.0 Received: by 10.52.91.17 with SMTP id ca17mr6724226vdb.56.1326740735659; Mon, 16 Jan 2012 11:05:35 -0800 (PST) Received: by 10.220.191.130 with HTTP; Mon, 16 Jan 2012 11:05:35 -0800 (PST) In-Reply-To: References: Date: Mon, 16 Jan 2012 11:05:35 -0800 Message-ID: From: Freddie Cash To: vip 71541 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: ipfw@freebsd.org Subject: Re: Problem with passive ftp in IPFW! X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2012 19:32:25 -0000 On Sun, Jan 15, 2012 at 10:36 PM, vip 71541 wrote: > Good morning, everybody. My name is Eugene. I know that not a new issue .= .. But > there is a problem as competently / properly write the rules for passive = ftp in > ipfw on a gateway for my LAN. Gateway running Freebsd 8.2p6. For kernal N= AT. > Now goes to the local network FTP on such rules here: > > 00159 =C2=A00 =C2=A0 =C2=A00 skipto 65000 tcp from 192.168.10.0/24 to any > dst-port21,1024-65535 > out xmit em0 keep-state > -- > 00211 skipto 65000 tcp from any 21,1024-65535 to ${wan_ip} =C2=A0in recv = em0 > -- > 65000 =C2=A00 =C2=A0 =C2=A00 nat 90 ip from any to any via em0 > --- Personally, I don't use skipto rules, as I find them to just cause confusion. At least at first. Once you have a working ruleset with several hundred/thousand rules in it, then skipto can be used to optimised things. You only have a NAT rule, you don't have any allow rules. The default rule (65535) in IPFW is "deny ip from any to any". Thus, if you don't explicity allow the traffic, then the packets are dropped. Personally, I also don't use stateful filter rules, just because of the poor way they interact with NAT in IPFW (at least with divert/natd; not sure if things are better with in-kernel NAT). Thus, the rules would be something like the following: ipfw add allow tcp from 192.168.0.0/24 to any 21,49152-65535 in recv ipfw add nat 90 tcp from 192.168.0.0/24 to any 21,49152-65535 out xmit ipfw add allow tcp from to any 21,49152-65535 out xmit ipfw add nat 90 tcp from any 21,49152-65535 to in recv established ipfw add allow tcp from any 21,49152-65535 to 192.168.0.0/24 in recv established ipfw add allow tcp from any 21,49152-65535 to 192.168.0.0/24 out xmit established The flow of the rules are: - allow traffic on the internal NIC - NAT the traffic going out the external NIC - allow the NAT'd traffic going out the external NIC And then reverse it for the incoming/return traffic - NAT the traffic coming in on the external NIC - allow the NAT'd traffic coming in on the external NIC - allow the traffic going out the internal NIC The established at the end of the rule catches only TCP packets that are part of the outgoing connection. The 49152-65535 is the default "ephemereal" port range on FreeBSD (and most TCP/IP using systems), used for things like FTP connections. It's a much smaller range. There's also FTP NAT tracking modules for IPFW, but I've never personally used any of them. --=20 Freddie Cash fjwcash@gmail.com