Re: IPFW2 layer2 support broken.
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
討論串 (同標題文章)
完整討論串 (本文為第 3 之 7 篇)：