Date: Wed, 23 Dec 2015 16:41:55 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: bycn82 <bycn82@gmail.com> Cc: Julian Elischer <julian@freebsd.org>, freebsd-ipfw@freebsd.org, Ganbold Tsagaankhuu <ganbold@gmail.com> Subject: Re: layer2 ipfw fwd Message-ID: <20151223155755.A8562@sola.nimnet.asn.au> In-Reply-To: <CAC%2BJH2x7bh=kq-n-7sniABSxTqox99kJRJeTfX%2BAyu3H=aE2sg@mail.gmail.com> References: <CAGtf9xOzJ%2BcL-W=HP5cd2nyabY=03AgTyFLvDuQWN-xB6KqjCg@mail.gmail.com> <567795F1.5080605@freebsd.org> <CAC%2BJH2xXVpnDfa5KUQGZ39uoqSiS5oB72ak6bAeaPqXgyCmd3Q@mail.gmail.com> <56780F5A.5060209@freebsd.org> <CAC%2BJH2yCJBQOctzMtnTDiFEbV_dQP3YVZ%2Bk6SwKej3ZpJaeHgw@mail.gmail.com> <5679F2E6.2090700@freebsd.org> <CAC%2BJH2x7bh=kq-n-7sniABSxTqox99kJRJeTfX%2BAyu3H=aE2sg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 23 Dec 2015 10:08:05 +0800, bycn82 wrote: > Cc: "freebsd-ipfw@freebsd.org" <freebsd-ipfw@freebsd.org>, > Ganbold Tsagaankhuu <ganbold@gmail.com> > Subject: Re: layer2 ipfw fwd > > Interesting, that means in order to filter the layer2 traffic with layer3 > filters. it will unpack the ether frame and get the packets. at least the > packet header. That's already been done. As Julian points out, at layer 2 you can see and work with ether headers (MAC addresses) _as well as_ the IP headers. > so why ipfw doesnt support this? Ipfw3 will support this! I would suggest reading this older but quite comprehensive article that applies specifically to bridges - and it was written for the old bridge, before if_bridge(4) so there are some syntactic differences, but should help with understanding the concepts and methodology. http://www.freebsd.org/doc/en/articles/filtering-bridges/article.html As that mentions, with a bridge you only get to see packets on their way in; once accepted they aren't passed to the firewall again - see PACKET FLOW in ipfw(8). All of this is well covered by that article, which is what I used back C. 2003 to create a very effective filtering bridge for an internet cafe-like environment off a satellite+ISDN router. It also mentions that: "Another limitation is that you are restricted to use only pass or drop commands for packets filtered by a bridge. Sophisticated things like divert, forward or reject are not available. Such options can still be used, but only on traffic to or from the bridge machine itself (if it has an IP address)." Which is presumably what Luigi's patch addresses, re forward anyway. There's always more to do :-) and contributions are welcome I'm sure. cheers, Ian > On Wednesday, 23 December 2015, Julian Elischer <julian@freebsd.org> wrote: > > > On 22/12/2015 10:57 PM, bycn82 wrote: > > > >> Hi Julian, > >> > >> Thanks for the explanation. > >> > >> Since it is on layer2, that means we can differentiate traffic by MAC or > >> other layer2 filters only. > >> e.g , forward the traffic when the type is 0x800 and destination MAC is > >> xx:yy:zz.... > >> > >> I meant the accuracy is a big concern. > >> > > since it is layer 2, it includes layer 3. IPFW knows how to access the > > layer 3 fields so layer 2 OR 3 may be used to filter. > > > > > >> Regards, > >> Bill Yuan > >> > >> > >> On 21 December 2015 at 22:40, Julian Elischer <julian@freebsd.org> wrote: > >> > >> On 21/12/2015 5:47 PM, bycn82 wrote: > >>> > >>> why fwd based on MAC? Can share more info of your requirement? > >>> > >>> > >>> you still decide to FWD based on IP address, but you do it while the > >>> packet is still in the layer 2 bridge. > >>> > >>> let me give you a concrete example > >>> > >>> If I have a bridge between two networks. it is a transparent bridge, in > >>> other words nothing sees the bridge. > >>> However using layer 2 IPFW, I can block packets from side A from getting > >>> to side B. > >>> In addition I can redirect (using ipfw fwd and this patch) packets that > >>> are coming in, from side A to port 80 on side B, to a local proxy or http > >>> filter. > >>> Everything else just flows back and forth across the bridge. > >>> Using IP spoofing/forwarding the proxy filter will create a socket that > >>> pretends to be the side B destination and respond directly, even though > >>> it > >>> doesn't have that address. It may in turn open a socket to the original > >>> destination and forward the request, or, maybe it won't, depending on > >>> policy. > >>> But nothing else is aware of its existence. it is as though a segment of > >>> cable started filtering web content. > >>> > >>> This is EXACTLY what the cisco/ironport web filter appliance does... > >>> > >>> > >>> > >>> > >>> On Monday, 21 December 2015, Julian Elischer < <julian@freebsd.org> > >>> julian@freebsd.org> wrote: > >>> > >>> On 21/12/2015 10:20 AM, Ganbold Tsagaankhuu wrote: > >>>> > >>>> Hi, > >>>>> > >>>>> Does ipfw support layer2 fwd to support transparent proxying on bridge? > >>>>> > >>>>> Does similar change like > >>>>> > >>>>> > >>>>> https://lists.freebsd.org/pipermail/freebsd-ipfw/2003-September/000526.html > >>>>> ever get committed? > >>>>> > >>>>> I don't believe this was applied.. > >>>> I did similar when I worked for Ironport/Cisco. > >>>> But it's a trade-off between bloat and usefulness. > >>>> > >>>> > >>>> thanks a lot, > >>>>> > >>>>> Ganbold
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20151223155755.A8562>