From owner-freebsd-net@freebsd.org Mon Aug 24 01:06:12 2015 Return-Path: Delivered-To: freebsd-net@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 421C79C166E for ; Mon, 24 Aug 2015 01:06:12 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from gw.catspoiler.org (unknown [IPv6:2602:304:b010:ef20::f2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gw.catspoiler.org", Issuer "gw.catspoiler.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 08E0A1CEC; Mon, 24 Aug 2015 01:06:12 +0000 (UTC) (envelope-from truckman@FreeBSD.org) Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2]) by gw.catspoiler.org (8.15.2/8.15.2) with ESMTP id t7O0qsFF002623; Sun, 23 Aug 2015 17:52:58 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201508240052.t7O0qsFF002623@gw.catspoiler.org> Date: Sun, 23 Aug 2015 17:52:54 -0700 (PDT) From: Don Lewis Subject: Re: a couple /etc/rc.firewall questions To: hrs@FreeBSD.org cc: freebsd-net@FreeBSD.org In-Reply-To: <20150823.084453.1715908115913144015.hrs@allbsd.org> MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 01:06:12 -0000 On 23 Aug, Hiroki Sato wrote: > Don Lewis wrote > in <201508222103.t7ML3gAx000794@gw.catspoiler.org>: > > tr> The example /etc/rc.firewall has provisions to use either in-kernel NAT > tr> or natd for the open and client firewall types, but the simple filewall > tr> type only has code for natd. Is there any reason that in-kernel NAT > tr> could not be used with the simple firewall type? > > I think there is no particular reason. Simple rule was just not updated. Yeah, it seems to work if I add the rule for it in the appropriate place. > tr> After allowing connections to selected TCP ports and then denying all > tr> other incoming TCP setup connections from ${oif}, the simple firewall > tr> code in /etc/rc.firewall then permits all other TCP setup connections: > tr> # Allow setup of any other TCP connection > tr> ${fwcmd} add pass tcp from any to any setup > tr> This is potentially undesirable since it allows unrestricted TCP > tr> connections between "me" and the inside network. When I changed this to > tr> ${fwcmd} add pass tcp from any to any out via ${oif} setup > tr> I was able to open TCP connections from the firewall box to the outside, > tr> but NATed connections from inside network to the outside were blocked. > tr> If I run "ipfw show", it appears that the TCP setup packets are falling > tr> through to the final implicit deny all rule, but I don't see any obvious > tr> reason. > > A TCP setup packet coming from a host on the internal LAN to the NAPT > router falls into the last deny-all rule because it does not match if > you added "out via ${oif}" to that rule. Does the following > additional rule work for you? > > ${fwcmd} add pass tcp from any to any out via ${oif} setup > ${fwcmd} add pass tcp from any to not me in via ${iif} setup That works for now, but won't do the correct thing when I subdivide my internal network because it will allow unrestricted connections between the internal subnets. What I'd really like is something like: ${fwcmd} add pass tcp from any to not me,${inet} setup but that isn't a valid rule. I ended up adding a couple of deny rules for me and ${inet} before the wildcard pass allow rule. I had to make sure that some other more specific rules allowing connections between me and the inside were before the new deny rules.