Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 25 Nov 2001 23:11:27 -0800
From:      "Ted Mittelstaedt" <tedm@toybox.placo.com>
To:        "Joost Bekkers" <joost@bps.jodocus.org>
Cc:        "Chuck Root" <puga@mauibuilt.com>, <freebsd-questions@FreeBSD.ORG>
Subject:   RE: IPFW/VLAN
Message-ID:  <000101c17649$90e06600$1401a8c0@tedm.placo.com>
In-Reply-To: <20011125184640.A3977@bps.jodocus.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Joost,

This is a tremendous simplification of the issue and isn't correct either.
I'm going to split hairs here and explain it in gory detail because there's
others that may wonder how FreeBSD bridging might be used with their
networks.

The type field is an ETHERNET, not an IP, standard.  Now, ARP packets,
by the standards definition, (RFC 826) are not permitted to cross networks.
(they are actually supposed to stay within physical networks but the concept
of bridging sort of bends that rule)  So, the idea that their type field would
change as the packet traveled through an internetwork is a moot issue - it
can't because an ARP packet can't travel through an internetwork.

However, if they _were_ allowed to be forwarded (as other TCP/IP
broadcasts can be forwarded if the router is set to allow it) then their
type would change, same as IP packets type would change, if they were
forwarded
on different media.  In short, the Ethernet type has nothing to do with
whether or not the packet is considered an IP packet.  The Ethernet type is
only for IP packets that happen to traverse an Ethernet network, it's a
concept that's bound to Ethernet.

If you look at the original e-mail from Robert Watson, you will note
that he does a bit of hand-waving on this issue, in fact specifically
mentioning ARP is passed.  The simple reason they can get away with this
is because ARP packets are never supposed to be routed and are always
supposed to be bridged.  So, it made someone's life a whole lot easier
to pretend that ARP packets aren't IP packets, even though they are.

In reality, what they are actually doing here is tying ipfw specifically
to Ethernet when it comes to treatment of ARP packets.  This
is philosophically wrong as a FreeBSD system could theoredically have
a broadcast-type interface on it in which ARP had meaning and Ethernet
typing didn't.  (for example, if someone wrote an ARCnet driver for it,
which is highly unlikely)

But you can't let philosophy get in the way of a running system, and the
default rule of treating ARP like a non-IP packet works, so that's why it's
done.
But don't get the idea that just because ipfw treats ARP as a non-IP
packet that it is.  ipfw is not the authoratative source of what constitutes
a TCP/IP packet.

Also, if you think about it you will realize that modification of ipfw to
filter IP packets that are _bridged_ is a ugly hack too.  Bridges are supposed
to be packet-neutral, and filtering should occur based on the MAC address,
nothing else.  Anything other than that is a layer 3 function and properly the
domain of a router.  However, the pressing need for so-called "transparent"
firewalls has
created a real need for this and it's easier to modify ipfw to filter bridged
IP traffic - even though it ties it to a media type - than to write a specific
"transparent firewall" kind of filter that's completely tied to Ethernet
interfaces only.

The biggest loss of NOT having an Ethernet-specific ipfw-like filtering
program, is that there's no convenient vehicle to use for adding in code
for filtering based on MAC addresses, which is certainly the domain of
a bridge.  There's a growing need in FreeBSD to write an
ipfw-like program that is for Ethernet interfaces only and that handles
MAC address filtering, spanning tree, VLAN filtering, and other
Ethernet-specific
protocols.  Handling NetBIOS and IPX filtering would be a real plus too,
although that would make it _very_ kludgy.  (but no worse than ipfw in my
opinion)

In summary, there's really only one use of the bridging code in FreeBSD -
the manufacture of transparent firewalls.  Don't get fooled by the word
"bridging" in the FreeBSD documentation - FreeBSD lacks a significant
amount of what network managers have come to expect that a real Ethernet
bridge can do.

Ted Mittelstaedt                                       tedm@toybox.placo.com
Author of:                           The FreeBSD Corporate Networker's Guide
Book website:                          http://www.freebsd-corp-net-guide.com


>-----Original Message-----
>From: Joost Bekkers [mailto:joost@bps.jodocus.org]
>Sent: Sunday, November 25, 2001 9:47 AM
>To: Ted Mittelstaedt
>Cc: Chuck Root; freebsd-questions@FreeBSD.ORG
>Subject: Re: IPFW/VLAN
>
>
>On Sun, Nov 25, 2001 at 09:23:17AM -0800, Ted Mittelstaedt wrote:
>> >
>> >The reason why 802.1q packets don't get filtered is this:
>> >The bridge code only sends ip packets through the firewall, all
>> >others (802.1q;ipx;arp;ipv6;....) will be passed no matter what.
>> >
>>
>> Ahem - ARP is an IP protocol...
>>
>
>To you and me it is. To the network however it is not.
>Ip has an ether_type of 0x0800
>Arp has an ether_type of 0x0806
>
>
>--
>greetz Joost
>joost@jodocus.org
>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?000101c17649$90e06600$1401a8c0>