From owner-freebsd-net@freebsd.org Mon Aug 24 01:01:29 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 CEDC39C1606 for ; Mon, 24 Aug 2015 01:01:29 +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 9DE921AE6; Mon, 24 Aug 2015 01:01:29 +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 t7O11Kgu002655; Sun, 23 Aug 2015 18:01:25 -0700 (PDT) (envelope-from truckman@FreeBSD.org) Message-Id: <201508240101.t7O11Kgu002655@gw.catspoiler.org> Date: Sun, 23 Aug 2015 18:01:20 -0700 (PDT) From: Don Lewis Subject: Re: a couple /etc/rc.firewall questions To: smithi@nimnet.asn.au cc: hrs@freebsd.org, freebsd-net@freebsd.org In-Reply-To: <20150823151421.G8515@sola.nimnet.asn.au> 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:01:30 -0000 On 23 Aug, Ian Smith wrote: > On Sun, 23 Aug 2015 08:44:53 +0900, 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. > > I did send you and -ipfw@ a patch for that on several occasions since > Feb. 2013, though I did fail to push it into the 3-4 PRs it affected. > > The attached patch addresses that, chooses kernel NAT over natd(8) if > both were enabled in rc.conf, updates some commentary and fixes an > overwordy line in 'workstation'. Just now checked it against HEAD. > > > 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 > > That looks ok, maybe some UDP too? Adding some stateful rules is > another option for dealing with inside hosts' external requests. I don't have a specific need for UDP between inside and outside, so I didn't bother with that. One end all my UDP connections is currently always the firewall box itself. I did just add stateful rules for TCPv6 between the inside and outside to replicate the stateful behaviour of TCPv4 NAT. > > ${fwcmd} add pass tcp from any to not me in via ${iif} setup > > If you want to deny inside hosts access to host services, that'll do it. > > The other long-term issue with 'simple' is that it permits no ICMPv4 at > all. Neither inside nor outside, no pings, no PMTU, nothing .. although > curiously allows selected ICMP for ipv6. I usually add something like: > > ${fwcmd} add pass icmp from any to any icmptype 0,3,8,11 > > If you don't want to allow pings from outside your net, preceded with: > > ${fwcmd} add deny icmp from any to any in recv ${oif} icmptype 8 Yeah, I alway end up adding ICMPv4 rules.