From owner-freebsd-pf@FreeBSD.ORG Wed Jun 28 09:02:52 2006 Return-Path: X-Original-To: freebsd-pf@freebsd.org Delivered-To: freebsd-pf@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 53B1C16A584 for ; Wed, 28 Jun 2006 09:02:52 +0000 (UTC) (envelope-from solinym@gmail.com) Received: from ug-out-1314.google.com (ug-out-1314.google.com [66.249.92.171]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5D884446FB for ; Wed, 28 Jun 2006 09:02:51 +0000 (GMT) (envelope-from solinym@gmail.com) Received: by ug-out-1314.google.com with SMTP id m3so212762uge for ; Wed, 28 Jun 2006 02:02:50 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Wnvc2yl6dxGx4CeuZQo4F6k8DSVSW73BCG0DXiXdvJQ/EagkmnMMgXPTaVAEH62SHP8KoZSzG9RV/Yzs+F/DJBo1SA/Pddz1rMRJoVUrUs/KDOcggJw8+5APIP70irayrjCw9YYz1Eqq459epBXwMH6yQC7IN/r7z2rDXKFboUQ= Received: by 10.78.185.7 with SMTP id i7mr82458huf; Wed, 28 Jun 2006 02:02:50 -0700 (PDT) Received: by 10.78.35.18 with HTTP; Wed, 28 Jun 2006 02:02:49 -0700 (PDT) Message-ID: Date: Wed, 28 Jun 2006 04:02:49 -0500 From: "Travis H." To: "Daniel Hartmeier" In-Reply-To: <20060627161102.GF14502@insomnia.benzedrine.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <44A1396C.7040708@gmail.com> <20060627161102.GF14502@insomnia.benzedrine.cx> Cc: freebsd-pf@freebsd.org Subject: Re: Keep State is not working on 6.1-RELAESE-p1 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Technical discussion and general questions about packet filter \(pf\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Jun 2006 09:02:52 -0000 On 6/27/06, Daniel Hartmeier wrote: > One common approach is to only filter incoming packets, and to let > everything pass out from the firewall. This covers all forwarded > traffic: anything leaving the firewall must first have passed in (and > has, therefore, been checked). It does not cover connections originating > from the firewall itself. But often, you either don't run any processes > on the firewall (that need to connect out), or you trust those > implicitely. One could also compromise and write a very short rule specific to the firewall's IPs, providing outbound filtering only for those source IPs. > Another common case is three (or more) legged firewall, where you have > strict policies about what interface a type of connection may enter and > where it may and may not leave (e.g. in on if1, out on if2, but never > out on if3), i.e. you don't trust the routing table (which might be > dynamically updated). In this case, you DO need per-interface rules, > and they are not really duplicates. Tagging helps in this case, too > (you'd tag passed incoming packets so they'd be allowed out on a > specific other interface). Often if one uses antispoof, one can eliminate the interface specifications entirely. In his case, he could also eliminate in/out entirely, and be left with a fairly terse ruleset. Note however that antispoof doesn't help too much if a particular interface leads to distant networks. Therefore, you shouldn't eliminate e.g. the WAN interface from rules, since antispoof won't prevent arbitrary Internet IPs from appearing on the non-WAN interfaces. -- `I put my heart and my soul into my work, and have lost my mind in the process.'' -- van Gogh | Security "guru" for rent or hire - http://www.lightconsulting.com/~travis/ -><- GPG fingerprint: 9D3F 395A DAC5 5CCC 9066 151D 0A6B 4098 0C55 1484