From owner-freebsd-ipfw@FreeBSD.ORG Sun Oct 24 12:35:56 2010 Return-Path: Delivered-To: ipfw@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 43C671065674; Sun, 24 Oct 2010 12:35:56 +0000 (UTC) (envelope-from lists.br@gmail.com) Received: from mail-qw0-f54.google.com (mail-qw0-f54.google.com [209.85.216.54]) by mx1.freebsd.org (Postfix) with ESMTP id CAE308FC24; Sun, 24 Oct 2010 12:35:55 +0000 (UTC) Received: by qwe4 with SMTP id 4so787516qwe.13 for ; Sun, 24 Oct 2010 05:35:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:subject:mime-version :content-type:from:in-reply-to:date:cc:content-transfer-encoding :message-id:references:to:x-mailer; bh=IGi4CVHtoQumHUuogNkqLQI2iR0KvccF5+g4yzF5Q6w=; b=Yrn4B1hWU/8d0oit1jgZBdmtoPpFun/8NfL5YLNQtVQEAXeNVnfs/ITr7w7097f6v6 C6tuGVdegVDXWmH/0RmT9ACk//XBBVDmQ65T5SkMeoUyEySToSBJE7pK7oBPr6uKmBVY WmRRWRgzCzL3JWPF8ocUPaj6BjG3yLk6p+7Po= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; b=iGjOW2TQSBcWSRG1nIJbbLOlINY5cJpQ8hyEERrWZD1o7CtBI3VKK1+STelBER7qXH lrUd4DUblEDu3M0piH6ha+L7A2BaTEiX4pDIpjfFI6b1ASB/zyi/YtdvxMyE0/lBUoXK +zERgmE0rwzwHHzDovfZU7BbF+2eK7xBc/O4U= Received: by 10.229.230.4 with SMTP id jk4mr4941253qcb.174.1287922352218; Sun, 24 Oct 2010 05:12:32 -0700 (PDT) Received: from [192.168.0.86] ([187.39.29.5]) by mx.google.com with ESMTPS id t35sm4828072qco.30.2010.10.24.05.12.29 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 24 Oct 2010 05:12:31 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Luiz Otavio O Souza In-Reply-To: Date: Sun, 24 Oct 2010 10:12:26 -0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CAA1E7B.1020107@freebsd.org> <4CAA45CC.8020304@freebsd.org> <4CAB8B35.7020703@freebsd.org> <4CACE7DE.9020106@freebsd.org> To: Eduardo Meyer X-Mailer: Apple Mail (2.1081) Cc: Brandon Gooch , Patrick Tracanelli , ipfw@freebsd.org, Julian Elischer , Adrian Chadd Subject: Re: layer2 ipfw 'fwd' support X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Oct 2010 12:35:56 -0000 On Oct 22, 2010, at 9:49 AM, Eduardo Meyer wrote: >>>=20 >>=20 >> To be clear, are we getting to the point of having the capability in >> ipfw of doing something like this in pf: >>=20 >> ... >> pass in quick on $INT_IF route-to lo0 inet proto tcp from any to >> 127.0.0.1 port 3128 keep state >> ... >=20 > Yes, pretty much that. >=20 >>=20 >> ...thus allowing true, transparent proxying? >>=20 >> I really thought that this was possible already with ipfw :( I need = to >> do some more reading... >>=20 >> I would be very interested in obtaining details on your final setup, >> once everything is in place and fully functioning :) >=20 > Right. I'm still working on that. We have separated grat things > working perfectly. Now I want to glue it together. TPROXY with > FreeBSD's IP_BINDANY works perfectly based on L3 redirection with > IPFW. Now we can do IPFW L2 redirection/forwarding. So I want to be > able to use both togerther, TPROXY with IPFW L2 forwarding. >=20 > I am investigating the code, learning, trying some tests; since I am > not a developer, not good at hacking 3rd party code, I am trying some > dirty tricks. Unsucessfull right now but still investigating. Hi Eduardo, I've not tried yet the TPROXY setup, but something come up in my = thoughts about this... The ipfw rule i was using to test the L2 fwd was something like this: ipfw fwd 127.0.0.1,3128 tcp from not me to any 80 And this rule forwards all the 'output' traffic on the bridge interface = to lusca. nice ! But with TPROXY lusca will try to connect to http servers with the = client IP and therefore all this traffic will also match the ipfw fwd = rule ! so, we end up with a loop and the game is over... I'm not sure yet (as i'd not tested this) if this is the only problem or = how we can workaround this limitation. We probably need to 'tag' the lusca packets someway and skip the fwd = rule. Regards, Luiz