From owner-freebsd-ipfw Thu Aug 19 17:15:57 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from alicia.nttmcl.com (alicia.nttmcl.com [216.69.69.10]) by hub.freebsd.org (Postfix) with ESMTP id A64BB15285 for ; Thu, 19 Aug 1999 17:15:51 -0700 (PDT) (envelope-from norman@nttmcl.com) Received: from localhost by alicia.nttmcl.com (8.8.5/3.5W(96/10/22)) id RAA21099; Thu, 19 Aug 1999 17:14:50 -0700 (PDT) Date: Thu, 19 Aug 1999 17:14:50 -0700 (PDT) From: Norman Nie Reply-To: Norman Nie To: Ludo Koren Cc: julian@whistle.com, freebsd-ipfw@FreeBSD.ORG Subject: Re: ipfw + bridging: fwd rule enacted but no effect In-Reply-To: <199908180740.JAA59933@t47.tempest.sk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Hi Ludo and Julian, Thank you very much for your reply. I understand ipfw better now. Yes the setup drawing was messed up during the delivery of the email and Julian's is what I originally intended. >> ... I spoke about it with Luigi Rizzo who has >> implemented the bridging stuff. He suggested that it's not >> appropriate for bridging as such. It should be done in `higher >> level'. But the problem is you need configuration as a gateway. [A]-----[fxp0:D:fxp1]-----[C] fxp2 ---- | | [B] Yes, I have experimented using D as a gateway. It worked even if A and C are all in the same subnet. Another thing, if you are concerned with ttl of the packets going through D, there is a new kernel option in freebsd4-current called IPSTEALTH that won't decrement the ttl. Thanks again, Norman Nie On Wed, 18 Aug 1999, Ludo Koren wrote: > > > I think it's possible that the question below shows a > > fundamental misunderstanding of what the fwd operation > > does.. When the packet arrives at B it will be forwarded > > by the normal code to the original destination,.. C > > > I think the picture below has been messed up.. I think it > > should be (by adding newlines and spaces) > > > [A]-----[fxp0:D:fxp1]-----[C] > > fxp2 ---- > > | > > | [B] > > > but I'm not sure.. > > I am not sure either... But if I understand the bridging code right it > is done sooner than the ipfw stuff is in the play. The ipfw check > routine is called from the bridging code. Here is the original comment > from the source (/sys/net/bridge.c): > > #ifdef IPFIREWALL > /* > * do filtering in a very similar way to what is done > * in ip_output. Only for IP packets, and only pass/fail/dummynet > * is supported. The tricky thing is to make sure that enough of > * the packet (basically, Eth+IP+TCP/UDP headers) is contiguous > * so that calls to m_pullup in ip_fw_chk will not kill the > * ethernet header. > */ > if (ip_fw_chk_ptr) { > ..... > > In the code which follows the above mentioned, the parameter where the > forwarding address should be returned is NULL. The forwarding address > is not handled at all. > > > > On Wed, 18 Aug 1999, Ludo Koren wrote: > > >> > >> > >> > I'm having problems with ipfw fwd + bridging. Please help! > >> > >> > My setup is: > >> > >> > [A]-----[fxp0:D:fxp1]-----[C] fxp2 ---- | | [B] > >> > >> > >> > >> > D is the box that runs ipfw + bridging. > >> > >> > My rule is very simple: > >> > >> > 100 fwd B log all from A to C > > > last rule allow from any to any > > >> > Ideally , it should redirect any packets from A to C and > >> emit > them out on interface fxp2 (linked to B). And those > >> packets > are to be dropped dead on B. > > > yes, but they might not be dropped, but possibly forwarded > > back to D (if net.inet.ip.forward is true) (or whatever it > > is..) > > >> > What happened is that logging messages indicate that rule > >> 100 > were envoked but with no effect. One can still ping from > >> A to > C. > > > >> > >> > >> > IPFW with no bridging (ie. machine B acting as a router) > >> works > fine. > >> > >> > Bridging alone works fine. > >> > >> > But when combining ipfw + bridging, the fwd command doesn't > > >> work. > > > hmmm tricky. I'm not very sure about bridging.. I haven't > > looked at it. > > >> > Any one has the same problem before? > >> > >> > Also, I assume when doing bridging, I don't need to config > >> the > routing table in machine B. Is this correct? > >> > >> Several days ago I sent similar question with no answer. After > >> looking into the source code I realized this feature is not > >> implemented. I spoke about it with Luigi Rizzo who has > >> implemented the bridging stuff. He suggested that it's not > >> appropriate for bridging as such. It should be done in `higher > >> level'. But the problem is you need configuration as a gateway. > >> > >> Basically, I was convinced to implement it, but now I am > >> considering if the solution is technically correct (e.g. I will > >> not get troubles if the load on bridge will be high). > >> > >> ludo > >> > >> > >> To Unsubscribe: send mail to majordomo@FreeBSD.org with > >> "unsubscribe freebsd-ipfw" in the body of the message > >> > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message