Date: Mon, 25 Jan 2016 11:52:36 -0700 From: "Russell L. Carter" <rcarter@pinyon.org> To: Ian Smith <smithi@nimnet.asn.au> Cc: freebsd-net@freebsd.org Subject: Re: ipfw NAT /etc/rc.firewall question Message-ID: <56A66EF4.40806@pinyon.org> In-Reply-To: <20160125155850.U50714@sola.nimnet.asn.au> References: <56A56F2D.2030200@pinyon.org> <20160125155850.U50714@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 01/24/16 23:25, Ian Smith wrote:
> On Sun, 24 Jan 2016 17:41:17 -0700, Russell L. Carter wrote:
> > Hi,
> >
> > I am making myself learn better how ipfw works. I am curious about
> > the optimal location of the NAT rule definition code. My immediate
> > application is a generic NATing gateway with an outside iface armored
> > up and an inside iface permitting general anarchy. The usual services
> > will be accessible to both sides. I plan to use kernel nat.
> > Looking at /etc/rc.firewall:
> >
> > In the "open" | "client" section, natd/kernel nat are configured prior
> > to other rules.
> >
> > In the "simple" section, natd only is configured after a bunch of
> > rules, and before a bunch more.
>
> Yes. The omission of kernel nat configuration (as well as just natd) in
> 'simple' is something I submitted patches for (to ipfw@) several times,
> several years ago, to no avail. If using 'simple', you need to manually
> add the kernel nat section, but omit the rulenumber (50). My patch just
> made this a function setup_nat(), called with or without a rulenmber.
Yeah I already planned on owning my rules file. I generally rip out
everything not explicitly required by my specific setup on that
particular system, so I'll just have a single kernel nat config.
I really like how easy it is to hook into the rc system, and define
my own variables for setting in rc.conf.
More below...
> > My question is, right after the natd configuration, are a bunch of
> > rules that specify deny rules for problematic addresses. Here's the
> > beginning and end of the section I'm curious about:
> >
> > ${fwcmd} add deny all from "table($BAD_ADDR_TBL)" to any via ${oif}
> > if [ -n "$inet6" ]; then
> > # Stop unique local unicast address on the outside interface
> > ${fwcmd} add deny all from fc00::/7 to any via ${oif6}
> > ${fwcmd} add deny all from any to fc00::/7 via ${oif6}
> > ...
> > ${fwcmd} add deny all from ff05::/16 to any via ${oif6}
> > ${fwcmd} add deny all from any to ff05::/16 via ${oif6}
> > fi
> >
> > Reading the comment before the nat configuration and also many
> > comments provided by the goog, suggests it's better to define as many
> > rules as possible before the nat config.
>
> In general I'd say the opposite is what's more usually suggested and
> implemented, but as ever, 'it depends ..'
>
> > But these rules are placed after. Can someone explain to me why this
> > is better|required? I suspect I am missing something possibly
> > important.
> >
> > This is stable/10.
>
> With 'open' and 'client' the nat rules are placed right after those in
> setup_loopback and setup_ipv6_mandatory so NAT is performed very early.
>
> With 'simple' we are the gateway for our inside network, so we need to
> block a) traffic from the outside from (e.g.) 192.168.0.0/16 when we're
> internally using addresses in that range - or any of the others listed -
> as coming in from outside these are (far from uncommon) bogons; and b)
> block any traffic outbound to the internet that (still) has an internal
> address, or any other bogus address we or any of our client boxes might
> try sending from.
>
> So we need to check inbound traffic (still TO our external address)
> before performing NAT, and check outbound traffic after NAT (now FROM
> our external address), which is what the placement of those rules either
> side of NAT does.
>
> Seems to me that all those ipv6 addresses could go into that table too,
> simplifying that section to a couple of rules, but since I don't well
> enough (ie hardly at all) understand ipv6 addressing, I'll leave that.
Ah, so taking this explanation back to the rules surrounding the
'simple' natd config it makes much more sense now.
Thanks!
Russell
> cheers, Ian
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56A66EF4.40806>