Date: Fri, 12 Jun 2015 17:03:28 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: John Reynolds <johnjen@reynoldsnet.org> Cc: freebsd-net@freebsd.org Subject: Re: question on NAT + IPFW Message-ID: <20150612155031.H74737@sola.nimnet.asn.au> In-Reply-To: <557A48A2.4090805@reynoldsnet.org> References: <557A48A2.4090805@reynoldsnet.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 11 Jun 2015 19:49:06 -0700, John Reynolds wrote: > Hello all, I've read in sections 30.4.4 and 30.4.3 of the handbook about > using IPFW and I've got some clarification questions. > > 1) When you're using any sort of firewall rules outside the > open/client/simple/closed, etc. pre-canned types in rc.firewall, but > instead using rules from a file, the way I read the handbook, you MUST > use specific "nat" rules (divert natd) in your ipfw file along with > setting "natd_enable" to YES. Correct? The handbook hasn't caught up with more recent (like >5 years) history; these days more people are using in-kernel NAT, for which there is a usage example in the 'client' ruleset in rc.firewall, but unfortunately not also the 'simple' ruleset, which would more suit your setup, unless you've drunk the "everything must be done statefully" kool-aid :) So sure, if using natd(8) then set natd_enable and use divert rule/s, or firewall_nat_enable=YES and nat rule/s (refer /etc/defaults/rc.conf). > 2) In the example found in 30.4.4 where it is using "stateful" rules, it > made specific mention that the "nat" stuff needed to be placed after the > rules to allow traffic in on the trusted interface but before the > "check-state" rule. Given that, if I wanted to completely block off one > of my local addresses would I also do it *before* the "divert natd" rule? Yes, blocking on ingress is the way to go, best done early unless e.g. you wanted to permit access to some internal services but not external. > I have a situation where I need to just simply "block all traffic" from > some teenagers' mobile devices after a certain period of the day (don't > ask .... teenagers......). So, would that rule look like this: > > $cmd 005 allow all from any to any via xl0 # exclude LAN traffic > $cmd 010 allow all from any to any via lo0 # exclude loopback traffic > > $cmd 020 deny log all from 192.168.1.20 to any via xl0 # new rule But that already allowed everything via xl0 at rule 5, You could do rule 5 _after_ blocking certain internal addresses, the order used here is not important, as long as it's before the divert (or nat) rule. > $cmd 100 divert natd ip from any to any in via $pif # NAT any > inbound packets That should rather specify 'ip4' as natd falls over handed ip6 packets. > $cmd 101 check-state > > (assuming 192.168.1.20 was the internal IP address for the mobile device > I want to thwart) Given you want to do this at certain times of day, rather than messing with the ruleset as you go I'd suggest using a table, perhaps like: $cmd 4 deny log all from table\(99\) to any in recv xl0 and using a system cron job - and/or manually as required - to either: /sbin/ipfw table 99 add 192.168.1.20 or /sbin/ipfw table 99 delete 192.168.1.20 as appropriate. > Would this accomplish what I'm hoping for? I currently don't have any > real FW to speak of--ipfw is there but the type is "open," so I'm trying > to learn as I go along in order to setup an actual firewall for this box > @ the same time. I'll suggest having a good look over 'simple' as perhaps a more suitable model for your sort of network, and using ipfw(8) as primary reference especially re tables and nat|natd usage, but you can add something like the above to any ruleset. The handbook doesn't even mention tables :( cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150612155031.H74737>