Date: Wed, 18 Aug 1999 09:40:43 +0200 (CEST) From: Ludo Koren <ludo_koren@tempest.sk> To: julian@whistle.com Cc: norman@nttmcl.com, freebsd-ipfw@FreeBSD.ORG Subject: Re: ipfw + bridging: fwd rule enacted but no effect Message-ID: <199908180740.JAA59933@t47.tempest.sk> In-Reply-To: <Pine.BSF.3.95.990817234319.11710B-100000@current1.whistle.com> (message from Julian Elischer on Tue, 17 Aug 1999 23:55:17 -0700 (PDT))
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908180740.JAA59933>