From owner-freebsd-pf@FreeBSD.ORG Wed Dec 5 15:21:48 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 42CDA8C9 for ; Wed, 5 Dec 2012 15:21:48 +0000 (UTC) (envelope-from ermal.luci@gmail.com) Received: from mail-qa0-f47.google.com (mail-qa0-f47.google.com [209.85.216.47]) by mx1.freebsd.org (Postfix) with ESMTP id E0F3A8FC12 for ; Wed, 5 Dec 2012 15:21:47 +0000 (UTC) Received: by mail-qa0-f47.google.com with SMTP id a19so2520826qad.13 for ; Wed, 05 Dec 2012 07:21:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=v7ZQqSuOfIWB18lZbzn2lejMyWPAgybW62veuC35+2w=; b=MRXgvR7ldYyD44hlNpJteGPMYxnUzBxlg+bHO8gecDIEmta2Wt+TypEeUX9F5+Xace kQR1F61UWaJgdCRPxvQ59NyVf01KTWNmA03BycO6tV5oUTnOerX3gX2ugqQjuuiRvpIg 1O+sJlrH/VkjV9My/2Mdd4iTT9vFXxs1+IOaeyzrDUMJxAV/nQW6s6FB7ar74KpMDwhW 46dpqTI0C/pxQkmpsYjjaZFzWJKcryPM3kc8l8foqCEIapGhXds7WSyyg43IxpesbLPE //u+eila14+tI28DH3WVp/THDemdiqHCGZs541BIH2xSB9Qr8HTps5dsS08rV1DDRhYE kV5A== MIME-Version: 1.0 Received: by 10.229.69.102 with SMTP id y38mr6743037qci.23.1354720907187; Wed, 05 Dec 2012 07:21:47 -0800 (PST) Sender: ermal.luci@gmail.com Received: by 10.49.121.163 with HTTP; Wed, 5 Dec 2012 07:21:47 -0800 (PST) In-Reply-To: References: <20121119235601.GK2692@verio.net> Date: Wed, 5 Dec 2012 16:21:47 +0100 X-Google-Sender-Auth: U0cfNpY_B_Yd3O8ycrNlXL10Awc Message-ID: Subject: Re: Routing return NAT traffic based on interface From: =?ISO-8859-1?Q?Ermal_Lu=E7i?= To: Peter McAlpine Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: fox@verio.net, "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: Wed, 05 Dec 2012 15:21:48 -0000 On Wed, Dec 5, 2012 at 3:51 PM, Peter McAlpine wrote: > First off, thanks for all the suggestions from both of you. My email > filters were messed up causing me to miss your replies. > > On 19 November 2012 18:56, David DeSimone wrote: > > If I understand the poster's problem, it is that there could be whole > > worlds of other networks behind $int_if, and he is not able to predict > > what IP addresses should be used to match that traffic; in fact, it is > > merely the fact that the traffic is arriving on $int_if that indicates > > it shoudl be NAT'd. > ^^ this is the problem exactly. > > Here's the config I have: > tun_if = "tap3" > ext_if = "xn0" > set skip on lo > nat on $ext_if from !$ext_if:network to any -> $ext_if > pass in on $tun_if from $tun_if:network to any keep state > pass out on $ext_if from any to any keep state > Maybe this can help, by writing the rules as follows. pass in on $tun_if from any to any tag TUNIFACE keep state pass in on $ext_if route-to ($tun_if $gateway_tun_if) from any to !self tag TUNIFACE keep state pass out on $tun_if reply-to ($ext_if $ext_if_gateway) from any to any tagged TUNIFACE keep state pass out on $ext_if reply-to ($tun_if $gateway_tun_if) from any to any tagged TUNIFACE keep state Then keep your other rules going... > I've attached a simple network diagram. If I ping google.com from a.b.c.d > the icmp traffic on 'server' goes out ext_if NAT'd, then comes back from > google.com, but then 'server' is trying to send it back out ext_if again > because 'server''s default route is the Internet. > > I can get the return traffic to go down the tunnel by manually adding a > route on 'server' to send traffic for a.b.c.0/24 down the tunnel, but then > I need to be aware of what all the networks behind 'client' are, and I > don't want to have to do that. > > Thanks again for all the ideas/input! > -Peter > > On Mon, Nov 19, 2012 at 7:46 PM, Kevin Wilcox >wrote: > > > On 19 November 2012 18:56, David DeSimone wrote: > > > > > This doesn't seem right, because even traffic coming in via the > external > > > interface will have its target IP changed to be the router, even if > > > it is destined for some other place. Previously you were using "from > > > $int_if:network" to prevent this from happening to other traffic, but > > > without that restriction, every packet would be subject to NAT. > > > > My assumption was that the traffic coming in on the external interface > > is already destined for the outside IP of the router, unless he's > > doing some really funky stuff on both sides ;) > > > > It sounded like he wanted to NAT anything coming from the inside > > interface and then anything on the outside that wasn't return NAT > > traffic was supposed to terminate on the router, but I've been known > > to have clogged ears and awfully poor eyesight. > > > > kmw > > > > _______________________________________________ > freebsd-pf@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-pf > To unsubscribe, send any mail to "freebsd-pf-unsubscribe@freebsd.org" > > -- Ermal