From owner-freebsd-pf@FreeBSD.ORG Mon Nov 19 20:12:55 2012 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 052B8CBC for ; Mon, 19 Nov 2012 20:12:55 +0000 (UTC) (envelope-from peter@aoeu.ca) Received: from homiemail-a56.g.dreamhost.com (caibbdcaaaaf.dreamhost.com [208.113.200.5]) by mx1.freebsd.org (Postfix) with ESMTP id CC6EC8FC14 for ; Mon, 19 Nov 2012 20:12:54 +0000 (UTC) Received: from homiemail-a56.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a56.g.dreamhost.com (Postfix) with ESMTP id 1ED47FE06C for ; Mon, 19 Nov 2012 12:12:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=aoeu.ca; h=mime-version :in-reply-to:references:date:message-id:subject:from:to:cc: content-type; s=aoeu.ca; bh=V0ekY9S71eeg2JvBUxStPv68j6M=; b=g0cB U/2jCphRm4KYsCoWgLV8cxGw5oBJFinfXRDqaY846pV5wtk+ddAXr0yAulvI9Dx8 Gs1J//muSnoZmFUQPQUSUMOVj+0ffpXLT0eqn9oWEXmTytjNIqveA2FEkr2Fbb50 5DEEUBDM3MUeQVGaFLBjq8v/FwO2HHg8umBB7BU= Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: peter@aoeu.ca) by homiemail-a56.g.dreamhost.com (Postfix) with ESMTPSA id 04DB2FE06B for ; Mon, 19 Nov 2012 12:12:30 -0800 (PST) Received: by mail-ob0-f182.google.com with SMTP id 16so6649553obc.13 for ; Mon, 19 Nov 2012 12:12:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.45.8 with SMTP id i8mr11684112obm.64.1353355967401; Mon, 19 Nov 2012 12:12:47 -0800 (PST) Received: by 10.60.64.73 with HTTP; Mon, 19 Nov 2012 12:12:47 -0800 (PST) In-Reply-To: References: Date: Mon, 19 Nov 2012 15:12:47 -0500 Message-ID: Subject: Re: Routing return NAT traffic based on interface From: Peter McAlpine To: Kevin Wilcox Content-Type: text/plain; charset=ISO-8859-1 Cc: freebsd-pf@freebsd.org X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.14 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: Mon, 19 Nov 2012 20:12:55 -0000 Thanks for your reply. I've tried the configuration you suggested but it's providing the same issue I was encountering before. My goal is to route all traffic from the tunnel out the external interface nat'ing it on the way out. Any traffic coming in on the external interface should be un-nat'd (if applicable), then sent back down the tunnel unless it's destined for the external interface's IP (post-un-nat). Is such a configuration possible with PF? -Peter On Fri, Nov 16, 2012 at 10:21 AM, Kevin Wilcox wrote: > On 16 November 2012 09:40, Peter McAlpine wrote: > >> data_if = "tap3" >> ext_if = "em0" >> set skip on lo0 >> nat on $ext_if from !$ext_if:network to any -> ($ext_if) >> pass in on $ext_if route-to $data_if from any to !$ext_if:network > >> The issue I'm having is that the 'pass' rule is not being matched (or >> even evaluated?). My default gateway on the router is the ext_if and >> return traffic is being reverse-translated and then the routing table >> is sending it back out ext_if instead of down data_if where I want it >> to go. > > That's because that's what your NAT rule is telling it to do. > > Your rule says "if I see traffic on the external interface that isn't > on the same network as the external interface, NAT it back out the > external interface" > > Your pass rule should never be used. Your external interface should > never see traffic coming into it that isn't destined for it. > > pf is smart enough to handle the return NAT traffic. > > I think you may have a misunderstanding of how NAT works. > > For simplicity sake, I'll use a fake internal network of 10.10.10.0/24 > and an outside Internet IP address of 4.4.4.4. Let's pretend the > internal interface has an IP of 10.10.10.254 and is the gateway for > the 10.10.10.0/24 network and that we will NAT their outbound traffic. > Now let's pretend there is a web-server at 25.25.25.25. > > When a computer inside my internal network, let's say 10.10.10.10, > wants to get to 25.25.25.25, it hits the gateway of 10.10.10.254. That > router then NATs the traffic. 25.25.25.25 sees a connection request > from 4.4.4.4. It sends back a reply. The router at 4.4.4.4 sees the > return traffic and pf checks its state table. It then changes the > destination for that traffic to be 10.10.10.10 and passes it out the > 10.10.10.254 interface. The whole point of RFC-1918 is that anyone can > re-use those IPs internally without conflicting with anyone else > because the IP seen by everyone else on the Internet is the *outside* > IP. > > A pf configuration to do that would look something like: > > ================== > > int_if=tun0 > ext_if=em0 > set skip on lo > > nat on $ext_if from $int_if:network to any -> $ext_if > pass in on $int_if from $int_if:network to any keep state > pass out on $ext_if from any to any keep state > > ================== > > Yes, that is being overly verbose and uses a little older syntax (keep > state, from any to any ) but it works on both OpenBSD and FreeBSD, and > it works on every release within the last few years (I still have > early 4.x OpenBSD routers and 7.x FreeBSD routers). > > Keep in mind that that configuration is *wide open*. > > kmw