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:
[begin]
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
interfaces.
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.
[end]
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
same)...
I basically assume this doesn't work because of this post made by Ted
Middelstadt a couple years ago
http://groups-beta.google.com/group/mailing.freebsd.questions/browse_frm/thread/79d023785ddc58ed/4e280a013b6325d4?tvc=1&q=vlan+trunk+ipfw+bridge+ted&hl=en#4e280a013b6325d4
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
match.
None are hitting:
00305 0 0 count ip from any to 56.199.242.178 layer2
mac-type 0x8100
00305 0 0 count ip from any to 56.199.242.178 mac-type
0x8100
00305 0 0 count ip from any to 56.199.242.178 mac-type
0x8100
00305 0 0 count ip from any to 56.199.242.178 mac-type
0x8100 via em1
00305 0 0 count ip from any to 56.199.242.82 mac-type
0x8100 via em1
00305 0 0 count ip from any to 56.199.242.82 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"
portion.
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).
Thanks,
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
---------------------------
_______________________________________________
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
