From owner-freebsd-questions@FreeBSD.ORG Sun Mar 9 20:30:24 2008 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AB2F7106566C for ; Sun, 9 Mar 2008 20:30:24 +0000 (UTC) (envelope-from norgaard@locolomo.org) Received: from mail.locolomo.org (97.pool85-48-194.static.orange.es [85.48.194.97]) by mx1.freebsd.org (Postfix) with ESMTP id 55FE38FC18 for ; Sun, 9 Mar 2008 20:30:24 +0000 (UTC) (envelope-from norgaard@locolomo.org) Received: from sleipner.local (unknown [192.168.0.62]) by mail.locolomo.org (Postfix) with ESMTP id 33AF11C0847; Sun, 9 Mar 2008 21:30:23 +0100 (CET) Message-ID: <47D448DE.2090907@locolomo.org> Date: Sun, 09 Mar 2008 21:30:22 +0100 From: Erik Norgaard User-Agent: Thunderbird 2.0.0.12 (Macintosh/20080213) MIME-Version: 1.0 To: Erik Wilson References: <47D4388A.2090604@locolomo.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: freebsd-questions@freebsd.org Subject: Re: Help with pf ruleset X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2008 20:30:24 -0000 Erik Wilson wrote: > I know you have cut away a lot of rules, but maybe that just makes > things more confusing. Try to nest your rules in the following order: > > direction - interface - protocol - src net - dst net - port/type > > You should need no "out" rules if you have "in" rules with keep state. > At each branch level make a catchup rule at the end with default action > and "quick" key word to make sure packets don't spill over and get > matched by other rules. > > > Good advice, thanks. I'm afraid i've tried so many different options > and variations to get this to work that it's not as pretty as it should > be. I got some of these rules from various examples posted on the web, > and tweaked them into unrecognizability ;) Do you think that Josh is > right about needing a route-to rule for the second WAN interface? It is absolutely possible that the problem is that the ping or response get sent the wrong way. Use snort to see what goes on. I did not analyze your setup to the point that I can tell you that. > Since you're handing out best practices ;) Is it better to use a nat > pass or rdr pass rule than seperate nat/rdr and pass statements? Why? I prefer to separate things. I know the less lines you have, the less lines can contain an error. But on the other hand, the less lines you have the more obscure and difficult to debug they become. It is very common that people believe they have errors in their filter rules when in fact it's nat rules that are wrong. When you have both rdr, nat and binat be careful to understand which order they take effect. They are first match. But since rdr is done on the way IN while nat is done on the way OUT, an rdr rule can take effect before the intended nat rule despite it being after the nat rule. So, to avoid such confusion, write first your rdr, then nat. Also, use the log statement in your nat rules while debugging. Cheers, Erik -- Erik Nørgaard Ph: +34.666334818 http://www.locolomo.org