From owner-freebsd-pf@FreeBSD.ORG Fri Nov 16 15:21:22 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 9D11CE6E for ; Fri, 16 Nov 2012 15:21:22 +0000 (UTC) (envelope-from kevin.wilcox@gmail.com) Received: from mail-da0-f54.google.com (mail-da0-f54.google.com [209.85.210.54]) by mx1.freebsd.org (Postfix) with ESMTP id 6DF578FC08 for ; Fri, 16 Nov 2012 15:21:22 +0000 (UTC) Received: by mail-da0-f54.google.com with SMTP id z9so1273586dad.13 for ; Fri, 16 Nov 2012 07:21:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=d9THt60Nklt8sc/qvFb6hLNEhv26TD7ubn47yijlbvg=; b=vBfur2AJ2LsD1/l4dYC/oQ1N72vIQGv5/wG9AUmCxCyatgKl4Y6yosiJYGcfP/oFHL zQ7W+HDhId7bnxLnBP+V5W2l6EOUlp8r1KL4NtI/fJb6bpQdQRCBpS6iN3OQZ9dDRYGU IHRBKnnFA12ZIHMkUWjeJq32Asb/2zfXRrsceD+O4wrP6i863spuYeKaRC6hpba3nkSI G3Wu1DsVJOrkLdG6nTB1KsBoRMFf5ZX5oQ1CjIK4PGHs6Bf0VNbEE6AqKb7FL/5ovlfW LKKNderXwzru5yfsdSBpN1KnJNVHJt0vJxX2je4W7h5DKUlYSIfhNSdtA7ihsIg6Tb7w MTww== MIME-Version: 1.0 Received: by 10.68.225.70 with SMTP id ri6mr5172104pbc.41.1353079281892; Fri, 16 Nov 2012 07:21:21 -0800 (PST) Received: by 10.68.8.2 with HTTP; Fri, 16 Nov 2012 07:21:21 -0800 (PST) In-Reply-To: References: Date: Fri, 16 Nov 2012 10:21:21 -0500 Message-ID: Subject: Re: Routing return NAT traffic based on interface From: Kevin Wilcox To: Peter McAlpine Content-Type: text/plain; charset=UTF-8 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: Fri, 16 Nov 2012 15:21:22 -0000 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