From owner-freebsd-net@freebsd.org Sun Aug 23 06:50:00 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 BBFC59C085F for ; Sun, 23 Aug 2015 06:50:00 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ob0-x22b.google.com (mail-ob0-x22b.google.com [IPv6:2607:f8b0:4003:c01::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 88F80CB9; Sun, 23 Aug 2015 06:50:00 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by obkg7 with SMTP id g7so89183310obk.3; Sat, 22 Aug 2015 23:49:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=g4ebMzFO5gaEYynGw2A9ojpZHUN9/OVDRxydrKa7YYw=; b=OVgmcbWl9ltzrxZRtJuUoiQpKwq8g9CUqcWY7u9ZxpixASOVyzrtH3Ucu9HukmpGjC F0oU6RKeTxhe8H/mIOCd/f8bdjQ92E/6NOFCdat+Jedt3qsPg1xqNhj6uARzblPq2FDy Hf3nInHnJQA2SNeP/+UIwHmqhbZUzvNKxVDPmXoenfbxr9esNb5u8oZ13fzeLVjF8Sps 1hKHbt+l3Lgq7GU4LhbAm24hc+0vf58Ez3xJLmenr1jOI19A8qk+U/ahUW6ob5kOSL06 XKzGWZqol5XkRreKvorMtgbcLtbZR7Ik2Y5bgWEJ9mB1SKIenklTlq9Vcmknxd0kvWPk BKdA== MIME-Version: 1.0 X-Received: by 10.60.94.210 with SMTP id de18mr15628218oeb.75.1440312599697; Sat, 22 Aug 2015 23:49:59 -0700 (PDT) Sender: kob6558@gmail.com Received: by 10.202.173.83 with HTTP; Sat, 22 Aug 2015 23:49:59 -0700 (PDT) In-Reply-To: <20150823151421.G8515@sola.nimnet.asn.au> References: <201508222103.t7ML3gAx000794@gw.catspoiler.org> <20150823.084453.1715908115913144015.hrs@allbsd.org> <20150823151421.G8515@sola.nimnet.asn.au> Date: Sat, 22 Aug 2015 20:49:59 -1000 X-Google-Sender-Auth: ZZixis7yFo3euYNk6gdfsNfnVZs Message-ID: Subject: Re: a couple /etc/rc.firewall questions From: Kevin Oberman To: Ian Smith Cc: Hiroki Sato , "freebsd-net@freebsd.org" , Don Lewis Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.20 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: Sun, 23 Aug 2015 06:50:00 -0000 On Sat, Aug 22, 2015 at 8:00 PM, 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. > > > ${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: > Not so curious. Without ICMPv6, IPv6 is effectively off. unlike IPv4 which will work fairly well without ICMP, though it will technically be broken and, for some cases will be REALLY broken. That's why network rc.firewall contains: setup_ipv6_mandatory() { [ $ipv6_available -eq 0 ] || return 0 ############ # Only in rare cases do you want to change these rules with the rules that allow normal IPv6 networking start when default deny is specified. Most importantly, NDP is required to get IPv6 to start (though there are work-arounds) and DAD is required to start it safely. This is a slightly touchy point with me as I filed a PR on this many years ago when such had not been added to rc.firewall. It was summarily closed with a message that proper security mandated that there be nothing allowed until they were put in place by firewall.conf (which ran WAY too late to do the job.) I don't recall who shot it down, but I was quite annoyed that someone who was clearly clueless about IPv6 would just toss a PR on a subject he didn't know. It was about a year before the standard rc.firewall started opening the required holes. I added this to mine as my old network started running IPv6 around the turn of the millennium and made it a production service in 2004, IIRC. -- Kevin Oberman, Network Engineer, Retired E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683