From owner-freebsd-ipfw Tue Aug 17 16:47: 9 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 D40B2157B9 for ; Tue, 17 Aug 1999 16:47:04 -0700 (PDT) (envelope-from norman@nttmcl.com) Received: from localhost by alicia.nttmcl.com (8.8.5/3.5W(96/10/22)) id QAA27815; Tue, 17 Aug 1999 16:46:15 -0700 (PDT) Date: Tue, 17 Aug 1999 16:46:15 -0700 (PDT) From: Norman Nie To: freebsd-ipfw@freebsd.org Subject: ipfw + bridging: fwd rule enacted but no effect 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 Hello, 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. 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. 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? Any commets highly appreciated. Thanks a lot, Norman Nie To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ipfw" in the body of the message From owner-freebsd-ipfw Tue Aug 17 23: 8:20 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from t47.tempest.sk (t47.tempest.sk [195.28.100.47]) by hub.freebsd.org (Postfix) with ESMTP id 0647014A0B for ; Tue, 17 Aug 1999 23:08:16 -0700 (PDT) (envelope-from ludo_koren@tempest.sk) Received: (from koren@localhost) by t47.tempest.sk (8.9.3/8.9.3) id IAA57956; Wed, 18 Aug 1999 08:08:46 +0200 (CEST) (envelope-from koren) Date: Wed, 18 Aug 1999 08:08:46 +0200 (CEST) Message-Id: <199908180608.IAA57956@t47.tempest.sk> From: Ludo Koren To: norman@nttmcl.com Cc: freebsd-ipfw@FreeBSD.ORG In-reply-to: (message from Norman Nie on Tue, 17 Aug 1999 16:46:15 -0700 (PDT)) Subject: Re: ipfw + bridging: fwd rule enacted but no effect Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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. > 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. > 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 From owner-freebsd-ipfw Tue Aug 17 23:57:54 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (Postfix) with ESMTP id 5A06514CAB for ; Tue, 17 Aug 1999 23:57:52 -0700 (PDT) (envelope-from julian@whistle.com) Received: from current1.whistle.com (current1.whistle.com [207.76.205.22]) by alpo.whistle.com (8.9.1a/8.9.1) with SMTP id XAA91619; Tue, 17 Aug 1999 23:54:08 -0700 (PDT) Date: Tue, 17 Aug 1999 23:55:17 -0700 (PDT) From: Julian Elischer To: Ludo Koren Cc: norman@nttmcl.com, freebsd-ipfw@FreeBSD.ORG Subject: Re: ipfw + bridging: fwd rule enacted but no effect In-Reply-To: <199908180608.IAA57956@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 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.. 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 From owner-freebsd-ipfw Wed Aug 18 0:40:20 1999 Delivered-To: freebsd-ipfw@freebsd.org Received: from t47.tempest.sk (t47.tempest.sk [195.28.100.47]) by hub.freebsd.org (Postfix) with ESMTP id 92B0D15627 for ; Wed, 18 Aug 1999 00:40:15 -0700 (PDT) (envelope-from ludo_koren@tempest.sk) Received: (from koren@localhost) by t47.tempest.sk (8.9.3/8.9.3) id JAA59933; Wed, 18 Aug 1999 09:40:43 +0200 (CEST) (envelope-from koren) Date: Wed, 18 Aug 1999 09:40:43 +0200 (CEST) Message-Id: <199908180740.JAA59933@t47.tempest.sk> From: Ludo Koren To: julian@whistle.com Cc: norman@nttmcl.com, freebsd-ipfw@FreeBSD.ORG In-reply-to: (message from Julian Elischer on Tue, 17 Aug 1999 23:55:17 -0700 (PDT)) Subject: Re: ipfw + bridging: fwd rule enacted but no effect Sender: owner-freebsd-ipfw@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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 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