From owner-freebsd-questions Sun Nov 25 23:11:44 2001 Delivered-To: freebsd-questions@freebsd.org Received: from mail.freebsd-corp-net-guide.com (mail.freebsd-corp-net-guide.com [206.29.169.15]) by hub.freebsd.org (Postfix) with ESMTP id 32F0837B416 for ; Sun, 25 Nov 2001 23:11:40 -0800 (PST) Received: from tedm.placo.com (nat-rtr.freebsd-corp-net-guide.com [206.29.168.154]) by mail.freebsd-corp-net-guide.com (8.11.1/8.11.1) with SMTP id fAQ7BSR43500; Sun, 25 Nov 2001 23:11:29 -0800 (PST) (envelope-from tedm@toybox.placo.com) From: "Ted Mittelstaedt" To: "Joost Bekkers" Cc: "Chuck Root" , Subject: RE: IPFW/VLAN Date: Sun, 25 Nov 2001 23:11:27 -0800 Message-ID: <000101c17649$90e06600$1401a8c0@tedm.placo.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20011125184640.A3977@bps.jodocus.org> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0 Importance: Normal Sender: owner-freebsd-questions@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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