Date: Fri, 12 Jun 2015 21:33:11 +1000 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Guido Falsi <mad@madpilot.net> Cc: John Reynolds <johnjen@reynoldsnet.org>, freebsd-net@freebsd.org Subject: Re: question on NAT + IPFW Message-ID: <20150612202813.K74737@sola.nimnet.asn.au> In-Reply-To: <557A9725.7050506@madpilot.net> References: <557A48A2.4090805@reynoldsnet.org> <557A80F8.1070109@madpilot.net> <557A835C.1090106@madpilot.net> <20150612174047.Q74737@sola.nimnet.asn.au> <557A9725.7050506@madpilot.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 12 Jun 2015 10:24:05 +0200, Guido Falsi wrote: > On 06/12/15 10:07, Ian Smith wrote: > > On Fri, 12 Jun 2015 08:59:40 +0200, Guido Falsi wrote: > > > > > > looks correct, assuming xl0 is your internal interface (better put it in > > > > a variable and use the variable in your rules imho) > > > > > > Forgot one thing, working around this block is as easy as changing the > > > machine IP, teenager can learn this easily and it can be done in a lot > > > of ways, even if they are not root(or equivalent) on their machine, they > > > can just boot from a CD with some live OS. You could have a better block > > > by also checking the MAC address, like this: > > > > > > $cmd 021 deny log MAC any 00:aa:00:00:00:00:01 via xl0 > > > > > > (not tested) > > > > > > MAC addresses can be modified too but it's somewhat more difficult. > > > > While that's all true, blocking at layer 2 requires extra work that may > > be beyond what's needed here, to have ipfw deal with layer 2 traffic. > > > > sysctl net.link.ether.ipfw=1 must be set for ipfw to see layer 2 packets > > at all, and then you'd need to follow ipfw(8) section PACKET FLOW to > > separate the layer 2 and 3 traffic in order to look at MAC addresses on > > the appropriate one of the extra two passes through ipfw this entails. > Uhm, I forgot to check these details. Yes, layer 2 is a lot more work > anyway, I avoid it if possible. > > I also did not read carefully the example given, my fault on that too :) Those examples are so wrong on so many counts that I never know where to even start on fixing them; I've banged on often enough about these to annoy some folks so I won't go on .. except that the first rule quoted: $cmd 005 allow all from any to any via xl0 # exclude LAN traffic is crazy in the context of wanting to do NAT on packets from the LAN bound for the outside interface. No checks, anti-spoofing, nothing. Need icmp for path MTU discovery? Too bad. Need UDP frags for such as zen.spamhaus.org responses, let alone DNSSEC? Tough. Expect ntpd to work over TCP port 37, or NETBIOS on TCP ports 137,138? Good luck .. Fortunately lev@ is working (in ipfw@) on some new stateful rule actions to decouple state setting and checking to avoid needing such as twisty skipto constucts for handling stateful rules, at which point updating the handbook might also be timely; I do have a few bits half-written. Take-away: ipfw(8) is your friend, and pretty much your only friend apart from what's in rc.firewall (and even that lacks proper icmp). cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150612202813.K74737>