IPFW2 layer2 support broken.

Gary Allan dragonfly at gallan.plus.com
Wed Jan 12 11:11:25 PST 2005


Daimao wrote:
I thought it was net.link.ether.bridge_ipfw=1 to enable IPFW at the
data link layer.  That and running it both on the data link layer and
network layer just seems like a bad idea, I usually disable IPFW at
the network layer when I do bridging (DUMMYNET).  Though I probably
misunderstood you completely and there's nothing but decaf in the
house right now T
This is taken from the ipfw man pages and explains the meaning of the 
various sysctl tunables.

^     to upper layers	 V
|			 |
+----------->-----------+
^			 V
[ip_input]	    [ip_output]   net.inet.ip.fw.enable=1
|			 |
^			 V
[ether_demux]    [ether_output_frame]  net.link.ether.ipfw=1
|			 |
+-->--[bdg_forward]-->--+	  net.link.ether.bridge_ipfw=1
^			 V
|	to devices	 |
I've tested in a bridge configuration and everything appears to work 
fine. The reason I run with net.link.ether_ipfw=1 is to perform MAC 
filtering on wi0. (This is the same IPFW2 config that I use on FreeBSD 
machines. I am aware of the limitations of MAC filtering!)

I mentioned it because it is similar to another problem I'm having with 
ipfw2 and divert sockets in that certain tcp packets disappear after 
being processed and accepted. (Received divert traffic from natd).

I've looked through the code but I don't understand any of it enough to 
find whats wrong. The ipfw(v1) code works with natd without issue but 
lacks a lot of ipfw2's features.

I'm looking at DragonFly because I think it's interesting and a possible 
upgrade path once BSD 4.11 is depreciated. OpenBSD's pf is looking a 
nice alternative to ipfw2 but I don't think anyone has ported the 
ability to tag packets in the OpenBSD bridge module based on MAC address 
to any of the other BSDs. (Maybe an good excuse to revamp all of my 
firewalls.)

Regards
G.Allan





More information about the Bugs mailing list