5.4 -- bridging, ipfw, dot1q

Dan Mahoney, System Admin danm at prime.gushi.org
Fri Aug 12 09:02:25 GMT 2005

Note:  I posted this to questions@ earlier, but upon further investigation 
of the issue, I realize that I basically need a "hack".

Warning, long.

My original question:


I'm setting up a bridging firewall where the packets are passing through 
on dot1q trunks.  Figure sixty or so.  Too many to create separate 

The bridge works.  Packet counts in the default match rule work (so I 
assume the bridge at least sees the packets).

Problem is, any "reasonable" rules (such as those which actually say to 
block traffic by ip or port or anything) aren't working
at all.  Not even logging counts.

Setting the "bridged" flag doesn't seem to help.

My only guess is that ipfw doesn't have the brains to look beyond the VLAN 
tags.  Is this the case?  Is this supported under 4.x (I'm using 5, but 
can downgrade), or is there any way AT ALL that I can get this to work?

As a note, snort and trafshow and everything else work fine analyzing the 
bridge traffic, it seems only the kernel has an issue.


Now my plea to hackers@:

>From what I can see, the packet type is mac, and that's the only rules 
that match.   I'm not 100 percent sure if this is because of the point at 
which this is being received, or because of the dot1q headers.  I have to 
assume it's the headers because, well, otherwise putting ipfw on a bridge 
would seem pretty silly to me.

I basically need minor mods done to the kernel code so that dot1q trunked 
traffic seen through a bridge is seen by ipfw rules (and matched by the 

I basically assume this doesn't work because of this post made by Ted 
Middelstadt a couple years ago


Of course, he says this:

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.

And ipfw2 basically addresses this.

This is what I see on my bridged packets with log:

Aug 11 23:38:43 fwi kernel: ipfw: 360 Accept MAC in via em1

I've tried every possible combination of arguments to ipfw which seem to 
None are hitting:

00305          0            0 count ip from any to layer2 
mac-type 0x8100
00305          0            0 count ip from any to mac-type 
00305          0            0 count ip from any to mac-type 
00305          0            0 count ip from any to mac-type 
0x8100 via em1
00305          0            0 count ip from any to mac-type 
0x8100 via em1
00305          0            0 count ip from any to layer2 
mac-type 0x

If this is possible with standard vanilla bridging and standard ipfw, 
please let me know, of course.  I'm guessing dot1q encapsulated traffic 
just doesn't match this.  I can match traffic with an "any to any mac-type 
vlan" or an "any to any layer2" rule.  But I think I can't match on more 
specific criteria (like an IP address) because the ipfw layer sees it as 
non-ip traffic, and doesn't even attempt to match it (even though I'm 
telling it specifically to do so), so it falls into the "silently passed" 

I don't know c.  And this is a bad time and place to learn.  The kernel 
code is also fairly streamlined, and I *really* don't have the time to 
learn structures and the like.  It's on my long-term to-do list, I swear.

Otherwise, I'm relatively sure this is less than an hour's worth of work, 
please someone let me know what it's worth to you and I'll make it happen.

(While I'lll be happy with a quick hack, this really is something that 
should probably at least have a sysctl or hooks in ipfw or something -- 
assuming anyone else finds it useful).


Dan Mahoney


"We need another cat.  This one's retarded."

-Cali, March 8, 2003 (3:43 AM)

--------Dan Mahoney--------
Techie,  Sysadmin,  WebGeek
Gushi on efnet/undernet IRC
ICQ: 13735144   AIM: LarpGM
Site:  http://www.gushi.org

More information about the freebsd-hackers mailing list