From owner-freebsd-net@FreeBSD.ORG Fri Jun 12 06:49:43 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 68F18780 for ; Fri, 12 Jun 2015 06:49:43 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (grunt.madpilot.net [78.47.145.38]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id E8F8519DD for ; Fri, 12 Jun 2015 06:49:42 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 3m7CMv2DkMzbll; Fri, 12 Jun 2015 08:49:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :references:subject:subject:mime-version:user-agent:from:from :date:date:message-id:received:received; s=mail; t=1434091769; x=1435906170; bh=tvYvEH+Sdtkb8ULU8Ra4XqDM158XO4G7VJVypWDnoSw=; b= PjX0mj+xj1Vpjf75jeyJydwcjJ9QfJKGBaWKCM57nwCZHqSrxHZ+twzshkURlR0Y 7RtLlSJR+OBsqQhYike3F70Me1SyZuaoyuDX2bTH9MrhzyLWUnl8pZNfNmcelAgG ZISQ57zmu67GEiPODk3gw8PVx/O7MVEbZXX6uPierI8= Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10024) with ESMTP id 2Lf94m4wCI-A; Fri, 12 Jun 2015 08:49:29 +0200 (CEST) Received: from tommy.madpilot.net (micro.madpilot.net [88.149.173.206]) by mail.madpilot.net (Postfix) with ESMTPSA; Fri, 12 Jun 2015 08:49:29 +0200 (CEST) Message-ID: <557A80F8.1070109@madpilot.net> Date: Fri, 12 Jun 2015 08:49:28 +0200 From: Guido Falsi User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: John Reynolds , freebsd-net@freebsd.org Subject: Re: question on NAT + IPFW References: <557A48A2.4090805@reynoldsnet.org> In-Reply-To: <557A48A2.4090805@reynoldsnet.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit 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 06:49:43 -0000 On 06/12/15 04:49, 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? Yes and no, with modern ipfw I'd suggest you use in kernel nat in place of userspace nat, it's orders of magnitude faster and can bear much higher loads. Documentation about it in the handbook is a lacking unluckily. You need to configure it with a command like: ipfw -q nat 1 config if pppoe0 same_ports this configures one instance. then use it like this: ipfw add 1000 nat 1 all from any to any in via pppoe0 it's almost the same as with natd, jut a sligthly different syntax. it's documented in ipfw(8). > > 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? Depends on how your firewall is structured, you should place any stateful rule(usually allow ones) after check-state, and block rules(which are not stateful usually) before it. This also helps lowering the firewall load, although with modern hardware it's really necessary to optimize firewalls only on fast links. For residential connectivity you're not likely to have speed problems in handling packets. > > 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 > > $cmd 100 divert natd ip from any to any in via $pif # NAT any > inbound packets > $cmd 101 check-state > > (assuming 192.168.1.20 was the internal IP address for the mobile device > I want to thwart) > > 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. looks correct, assuming xl0 is your internal interface (better put it in a variable and use the variable in your rules imho) Making a complex ruleset requires some work and testing, it's not easy to get it right the first time, especially when one starts using it. Hope this helps! -- Guido Falsi