From owner-freebsd-pf@FreeBSD.ORG Wed Feb 3 20:17:57 2010 Return-Path: Delivered-To: freebsd-pf@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 055E9106566C for ; Wed, 3 Feb 2010 20:17:57 +0000 (UTC) (envelope-from stefanferreira@gmail.com) Received: from mail-vw0-f54.google.com (mail-vw0-f54.google.com [209.85.212.54]) by mx1.freebsd.org (Postfix) with ESMTP id A8C6E8FC15 for ; Wed, 3 Feb 2010 20:17:56 +0000 (UTC) Received: by vws11 with SMTP id 11so942175vws.13 for ; Wed, 03 Feb 2010 12:17:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=PlJvllCqVN1IaLUB6+mfa8ROMgY42nqUxIzl4XbgTAo=; b=O9iZCnHxch7zgzMCPAndlBr3aEmDDpWTjIZydhMTsHQP1kQxet/7OTyuIGQdepSh2/ 9hGUyblsy8x16+5fR9MowqqJ+vehaTpfkip2wnu0qNjZd7B/qUuddAY7EBvkcRr/IOgU Wxzu9CwyUbwDza1Tb0QqPm3ZtIxLKZgvJPt6s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=oJ9leBS6jlHrc55PK55NEP4z8jSW0V55mQU8khTn3usOrp+4FMhZTFATMRaB+L70fw Wp1KnM0nmViuB1HBtMuj1+mQlsn0haUKC7cO4+XYw4KxD7pn6cw1Pb6DKvkTmD8DDO3W p/ktCRT3iCxtmcVAuOMHalV4IiZdGVZonjjHM= Received: by 10.220.108.83 with SMTP id e19mr243469vcp.118.1265228271370; Wed, 03 Feb 2010 12:17:51 -0800 (PST) Received: from ?192.168.8.120? (196-215-4-63.dynamic.isadsl.co.za [196.215.4.63]) by mx.google.com with ESMTPS id 25sm83627931vws.20.2010.02.03.12.17.47 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 03 Feb 2010 12:17:50 -0800 (PST) Message-ID: <4B69D9E4.2040705@gmail.com> Date: Wed, 03 Feb 2010 22:17:40 +0200 From: Stefan User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.5) Gecko/20091204 Lightning/1.0b1 Thunderbird/3.0 MIME-Version: 1.0 To: jhell References: <4B6866D5.4060405@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-pf@freebsd.org Subject: Re: toute-to on lo0 not working? X-BeenThere: freebsd-pf@freebsd.org X-Mailman-Version: 2.1.5 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, 03 Feb 2010 20:17:57 -0000 Wouldn't the same problem then apply? By the time pf sees packets originating on the pf box itself, they are already outbound on a specific interface, and cannot be routed to the correct interface. I think I'll have to use rtables after all. That just means I'm limited to destination routing only and not full policy routing. It also seems that the "loopback" option (two bridged tap interfaces) can't work because the packets always bypass the actual full stack of the interfaces. The only weird thing with that is that when I set my default route to tap0 and block inbound on tap1 (bridged to tap0), the pings are stopped, but when I pass the traffic it does loop until TTL expires. This suggests that pf does indeed see those packets, yet when I try to apply routes to them inbound on tap1, they go nowhere... I'm convinced that I just don't know the interactions between pf nat, pf route-to and rtables well enough to crack this one... On 2010-02-03 04:59, jhell wrote: > > On Tue, 2 Feb 2010 12:54, stefanferreira@ wrote: >> Hi >> >> In my quest to route traffic originating on the freebsd machine, I've >> managed to loop back outbound traffic via lo0 so that I can try and >> route it inbound on lo0 (pf can't apply route-to logic to outbound >> traffic; by then it's to late to try and route it over a different >> interface). >> >> The loopback works when I switch off skip on lo0, and pass all lo0 >> traffic, so that traffic is definitely processed by pf. I also know >> the looping works, because when I try to ping an outside IP, I get a >> response that the TTL has been exceeded, and traceroute shows >> repeating entries of 127.0.0.1 (in other words, the packets jost loop >> back through the pf box repeatedly till their TTL is exceeded). >> >> The problem is the moment I change my rule to try and route the >> inbound traffic on lo0, the packets just seem to go nowhere. They are >> not routed correctly and I can't tell what happens to them. In the >> ruleset below, enabling the second rule results in the packets >> looping back to the pf box repeatedly, and the first rule results in >> the packets "disappearing". The only difference is the route-to >> statement, which works for all traffic originating elsewhere on the lan. >> >> #pass in quick on lo0 route-to (adsl-int0 196.210.140.129) from any >> to ! $IPs_LAN $KEEPSTATE $ALTQ_DEFAULT label zSA_Local tag zSA_Local >> #pass in quick on lo0 from any to ! $IPs_LAN $KEEPSTATE $ALTQ_DEFAULT >> label zSA_Local tag zSA_Local >> pass out quick all $KEEPSTATE tagged zSA_Local >> pass quick on lo0 >> >> Please help! I really need to route traffic originating on the pf box >> via pf, and not via rtables! >> > > Have you tried implementing "binat" and possibly making use of rdr > while using some tables to hold your addresses and subnets ? > > # BINAT > # Translate outgoing packets' source address (any protocol). > # Translate incoming packets' destination address to an internal machine > # (bidirectional). > binat on $ext_if from 10.1.2.150 to any -> $ext_ifA > > you could change that to: > binat on $ext_if from to any -> $ext_ifA > > Looping traffic that is originating internally back around to a > loopback interface is not going to solve this, and it will cause you a > lot more frustration. > > Best of luck. >