a couple /etc/rc.firewall questions

[Kevin Oberman]

On Sat, Aug 22, 2015 at 8:00 PM, Ian Smith <smithi at nimnet.asn.au> wrote:

> On Sun, 23 Aug 2015 08:44:53 +0900, Hiroki Sato wrote:
>  > Don Lewis <truckman at FreeBSD.org> wrote
>  >   in <201508222103.t7ML3gAx000794 at 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 at gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683