From owner-freebsd-pf@FreeBSD.ORG Wed May 13 02:25:34 2015 Return-Path: Delivered-To: freebsd-pf@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 69C44F5C for ; Wed, 13 May 2015 02:25:34 +0000 (UTC) Received: from fedex2.jetcafe.org (fedex2.jetcafe.org [205.147.26.23]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3C32918F0 for ; Wed, 13 May 2015 02:25:30 +0000 (UTC) X-Envelope-To: Received: from [205.147.26.4] (hokkshideh.jetcafe.org [205.147.26.4]) by fedex2.jetcafe.org (8.14.9/8.14.9) with ESMTP id t4D2PO15082194 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 12 May 2015 19:25:24 -0700 (PDT) (envelope-from dave@jetcafe.org) Message-ID: <5552B614.4080502@jetcafe.org> Date: Tue, 12 May 2015 19:25:24 -0700 From: Dave Hayes User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: freebsd-pf@FreeBSD.org Subject: Pf, rtable, and rdr...bug? Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -1 ( out of 6) ALL_TRUSTED,SHORTCIRCUIT X-Spam-Checker-Version: SpamAssassin version 3.4.0 X-Scanned-By: MIMEDefang 2.75 on 205.147.26.23 X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.20 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, 13 May 2015 02:25:34 -0000 [ Resending this to the PF list in hopes of some insight. Thanks. ] Hello everyone. I'm having a problem with using rdr in an existing pf that uses rtable. I'm running 10.1-STABLE #0 r282154 and I believe this is a bug, but it could also be something I haven't spotted. I have a firewall with three interfaces. The ip addresses have been changed to protect the innocent. :) - a slow net (1.2.3.0/24) interface: em0 @ 1.2.3.10 - a fast net (4.5.6.0/24) interface: em1 @ 4.5.6.10 - an internal net (192.168.4.0/24) interface: em2 @ 192.168.4.10 I route the internal net traffic over the fast cable net, and allow the internet net to access machines on the slower work net. Both default routes for the slow and fast net are .1 addresses (e.g. 1.2.3.1 and 4.5.6.1). I use an alias on both the slow and fast net (.42) to route the traffic from so I can see what's going on. I have net.fibs="2" in loader.conf and two different default routes set up for each fib. The default "default route" (fib 0) is 1.2.3.1. Here's my pf ruleset that works, paraphrased. $slow_net = "1.2.3.0/24" $slow_if = "em0" $slow_nat_ip = "1.2.3.42" $fast_net = "4.5.6.0/24" $fast_if = "em1" $fast_nat_ip = "4.5.6.42" $int_net = "192.168.4.0/24" $int_if = "em2" $int_ip = "192.168.4.10" # I don't alias this side table const { 10/8, 172.16/12, 192.168/16 } nat log in $fast_if inet from $int_if:network to ! $slow_net -> $fast_nat_ip nat log on $slow_if inet from $int_if:network to $slow_net -> $slow_nat_ip block in log all antispoof log quick for { $slow_if $fast_if $int_if } pass in log quick on $int_if inet from $int_net to !$slow_if:network modulate state rtable 1 pass in log quick on $int_if inet from $int_net to $slow_if:network modulate state rtable 0 pass log on $slow_if inet from ! to any modulate state pass out log inet from any to any modulate state So I tried to use rdr to forward some ports from the to a machine on the internal net: $webserver = "192.168.4.22" .... rdr on $fast_if inet proto tcp from any to port 80 -> $webserver This doesn't work. When I turn on tcpdump on all three interfaces, I see the packets coming in from the fast net to the internal net. The responses are appearing on the slow net, with the IP addresses of the fast net. So if I see this from em1: 14:34:11.887357 IP 10.11.12.13:18600 > 4.5.6.42:80 ... I then see the response...but on em0: 14:34:12.087283 IP 4.5.6.42:80 > 10.11.12.13:18600 ... Why doesn't this response packet go out the proper interface? Thanks in advance for any insight. If I don't hear from anyone, I'm going to assume this is a bug and file a bug report. -- Dave Hayes - Consultant - Altadena CA, USA - dave@jetcafe.org >>>> *The opinions expressed above are entirely my own* <<<< A path and a gateway have no meaning or use once the objective is in sight.