IPFW/VLAN
Richard Puga
The MTU of the fxp cards it set to its new default of 1500 (as of 4.4) and
curiously enough
can not be set higher as the maximum length of an ether net packet is 1518.
The bridge passes the 802.1q packets just fine and I can view them with
tcpdump.
it seems that ipfw ignores them, either treating them as a malformed ether
net packet or one that
is not ip.. im not sure that's just a guess..
Thanks for your reply
Richard Puga
pu...@mauibuilt.com
Dru wrote:
> On Fri, 23 Nov 2001, Chuck Root wrote:
>
> > I am trying to use a freebsd box with 2 fxp NIC's in it as a firewall
> > between 2 points on a 802.1q tagged vlan trunk.
> >
> > I am bridging the interfaces using the BRIDGING option in the kernel and
> > I am using ipfw to filter pakets.
> >
> > The bridge and ipfw work fine with normal pakets but the ones with
> > 802.1q tages slip right on by.
> >
> > is there any way to do this?
> >
> > I have tried bridging the vlans them selfs with no luck.
>
> Hi Richard,
>
> Do you have the following line in your kernel config file?
>
> pseudo-device vlan 2
>
> Also, what is the MTU on the fxps?
>
> HTH,
>
> Dru
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message
Ted Mittelstaedt
>From: owner-freeb...@FreeBSD.ORG
>[mailto:owner-freeb...@FreeBSD.ORG]On Behalf Of Joost Bekkers
>Sent: Sunday, November 25, 2001 1:21 AM
>To: Chuck Root
>Cc: freebsd-...@FreeBSD.ORG
>Subject: Re: IPFW/VLAN
>
>
>On Fri, Nov 23, 2001 at 10:38:36PM -1000, Chuck Root wrote:
>> I am trying to use a freebsd box with 2 fxp NIC's in it as a firewall
>> between 2 points on a 802.1q tagged vlan trunk.
>>
>> I am bridging the interfaces using the BRIDGING option in the kernel and
>> I am using ipfw to filter pakets.
>>
>> The bridge and ipfw work fine with normal pakets but the ones with
>> 802.1q tages slip right on by.
>>
>> is there any way to do this?
>>
>> I have tried bridging the vlans them selfs with no luck.
>>
>
>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...
>The reason why you can't bridge the vlan interfaces is because
>bridging only works on ethernet interfaces.
>
>At this point there is nothing you can do about it. (aside from
>changing the kernel code)
>
See
http://www.freebsd.org/cgi/getmsg.cgi?fetch=45862+48717+/usr/local/www/db/text
/2001/freebsd-stable/20010211.freebsd-stable
for a message from one of the kernel developers as to why ipfw cannot
filter bridged packets.
Consider that ipfw gets it's name from IP = Internet Protocol + FW Firewall.
As others have pointed out a program intended for filtering IP packets
is not the correct vehicle for filtering bridged packets.
There's been periodic interest in writing a bridge filter, however nobody
has stepped forward to do the work.
I'll point out, though, that hubs that have management and filtering
capability built into them are not that expensive.
Ted Mittelstaedt te...@toybox.placo.com
Author of: The FreeBSD Corporate Networker's Guide
Book website: http://www.freebsd-corp-net-guide.com
>--
>greetz Joost
>jo...@jodocus.org
Richard Puga
if I do a tcp dump on fxp0 or fxp1 I see normal paketw with simple 801.1Q #10 in
them.
its thease packets that ipfw ignores, hence my problem..
Thanks again for your reply
Richard Puga
pu...@mauibuilt.com
PS if I do a tcpdump on the vlan interfaces I set up on the bridge I get no
traffic..
all the traffic seems to go from fxp0 to fxp1 and if I tell ipfw to block all
traffic from fxp0 to fxp1 the 802.1q packets still get through
I tried bridging fxp0 to vlan0 and fxp1 to vlan1 and vlan0 to vlan1 yada yada
yada....
:)
Dru wrote:
> On Sat, 24 Nov 2001, Richard Puga wrote:
>
> > Yes I do have the vlan entry in my kernel. I have tried it with and without.
> >
> > The MTU of the fxp cards it set to its new default of 1500 (as of 4.4) and
> > curiously enough
> > can not be set higher as the maximum length of an ether net packet is 1518.
> >
> > The bridge passes the 802.1q packets just fine and I can view them with
> > tcpdump.
> >
> > it seems that ipfw ignores them, either treating them as a malformed ether
> > net packet or one that
> > is not ip.. im not sure that's just a guess..
> <snip>
>
> Hi Richard,
>
> Keep the vlan stuff in your kernel as it's needed; the number after the
> pseudo-device represents how many vlans you want to support.
>
> You should then be able to ifconfig each virtual vlan interface. See "man
> ifconfig" and do a search for vlan as you have to set your vlan tag. An
> example of the syntax is also given in the updated todo section of number
> 3 here:
>
> http://www.euitt.upm.es/~pjlobo/fbsdvlan.old.html
>
> You'll probably have to adjust your ipfw ruleset to accomodate these
> virtual interfaces so you might want to turn off the firewall first to see
> if you can pass the traffic, then adjust your ruleset accordingly.
>
> Good luck,
>
> Dru
Ted Mittelstaedt
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 te...@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:jo...@bps.jodocus.org]
>Sent: Sunday, November 25, 2001 9:47 AM
>To: Ted Mittelstaedt
>Cc: Chuck Root; freebsd-...@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
>jo...@jodocus.org