From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 11:33:21 2015 Return-Path: Delivered-To: freebsd-net@hub.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EB81A55E for ; Fri, 12 Jun 2015 11:33:21 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CA7241816 for ; Fri, 12 Jun 2015 11:33:19 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t5CBXB3p090152; Fri, 12 Jun 2015 21:33:13 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 12 Jun 2015 21:33:11 +1000 (EST) From: Ian Smith To: Guido Falsi cc: John Reynolds , freebsd-net@freebsd.org Subject: Re: question on NAT + IPFW In-Reply-To: <557A9725.7050506@madpilot.net> Message-ID: <20150612202813.K74737@sola.nimnet.asn.au> References: <557A48A2.4090805@reynoldsnet.org> <557A80F8.1070109@madpilot.net> <557A835C.1090106@madpilot.net> <20150612174047.Q74737@sola.nimnet.asn.au> <557A9725.7050506@madpilot.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2015 11:33:22 -0000 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