Date: Sun, 23 Aug 2015 18:01:20 -0700 (PDT) From: Don Lewis <truckman@FreeBSD.org> To: smithi@nimnet.asn.au Cc: hrs@freebsd.org, freebsd-net@freebsd.org Subject: Re: a couple /etc/rc.firewall questions Message-ID: <201508240101.t7O11Kgu002655@gw.catspoiler.org> In-Reply-To: <20150823151421.G8515@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23 Aug, Ian Smith wrote:
> On Sun, 23 Aug 2015 08:44:53 +0900, Hiroki Sato wrote:
> > Don Lewis <truckman@FreeBSD.org> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201508240101.t7O11Kgu002655>