From owner-freebsd-pf@FreeBSD.ORG Fri Mar 4 17:56:29 2005 Return-Path: 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 BF65F16A4CE for ; Fri, 4 Mar 2005 17:56:29 +0000 (GMT) Received: from atlas.spiretech.com (atlas.spiretech.com [207.173.200.232]) by mx1.FreeBSD.org (Postfix) with ESMTP id AEDC543D53 for ; Fri, 4 Mar 2005 17:56:28 +0000 (GMT) (envelope-from netbsd-pf@shelton.ca) Received: from [192.168.0.110] (ben.shelton.ca [207.173.201.46]) (authenticated) by atlas.spiretech.com (8.11.6/8.11.6) with ESMTP id j24HuHL32479; Fri, 4 Mar 2005 09:56:17 -0800 Message-ID: <4228A136.30707@shelton.ca> Date: Fri, 04 Mar 2005 09:56:06 -0800 From: Ben Shelton User-Agent: Mozilla Thunderbird 1.0 (Macintosh/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Hartmeier References: <42289DEA.5050205@shelton.ca> <20050304174927.GC6369@insomnia.benzedrine.cx> In-Reply-To: <20050304174927.GC6369@insomnia.benzedrine.cx> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit cc: freebsd-pf@freebsd.org Subject: Re: pf routing issue? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.1 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: Fri, 04 Mar 2005 17:56:29 -0000 Daniel Hartmeier wrote: > On Fri, Mar 04, 2005 at 09:42:02AM -0800, Ben Shelton wrote: > > >>pass in quick inet proto tcp from any to x.x.x.x keep state > > > This allow only incoming packets (on any interface). It does not allow > packets to go out through any interface. Even if a packet first comes in > on one interface, and is then routed out through another interface, that > second step is blocked, because the rule does not allow packets to go > out through any interface. What else did you expect the 'in' option in > that rule to do? > > If I understand you correctly, you've been trying to connect _from_ the > firewall to another host (getting the 'no route to host' error, which > has a new additional meaning, issued also when pf blocks an outgoing > packet from a local socket), so you should expect outgoing packets on > some interface... I'm actually trying to connect from an outside host through the firewall to a host behind the firewall. I understood that the keep state would handle the return packet, am I wrong here? Also, at various times during the testing I had included a second rule: pass out quick inet proto tcp from x.x.x.x port 80 to any keep state as well. I can't guarantee that I did this in a completely orderly fashion (it was the middle of the night), but this didn't work then. I *think* I have the basics down here, but there probably is something completely braindead I've done. Thanks for the response. Ben