Date: Thu, 19 Aug 1999 17:14:50 -0700 (PDT) From: Norman Nie <norman@nttmcl.com> To: Ludo Koren <ludo_koren@tempest.sk> Cc: julian@whistle.com, freebsd-ipfw@FreeBSD.ORG Subject: Re: ipfw + bridging: fwd rule enacted but no effect Message-ID: <Pine.GSO.3.95LJ1.1b4.990818114114.5893E-100000@alicia.nttmcl.com> In-Reply-To: <199908180740.JAA59933@t47.tempest.sk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.3.95LJ1.1b4.990818114114.5893E-100000>