Date: Fri, 12 Aug 2005 06:33:59 -0700 From: Luigi Rizzo <rizzo@icir.org> To: "Dan Mahoney, System Admin" <danm@prime.gushi.org> Cc: hackers@freebsd.org Subject: Re: 5.4 -- bridging, ipfw, dot1q Message-ID: <20050812063359.A14229@xorpc.icir.org> In-Reply-To: <20050812042749.H87994@prime.gushi.org>; from danm@prime.gushi.org on Fri, Aug 12, 2005 at 05:07:13AM -0400 References: <20050812042749.H87994@prime.gushi.org>
next in thread | previous in thread | raw e-mail | index | archive | help
I am afraid the existing code cannot help you.
The packets you see are encapsulated in 802.1q aka VLAN frames,
and since ipfw2 does not try to decapsulate the packets, you
don't get to see the IP headers.
Your most reasonable option would be to write a new ipufw2 opcode,
say something like 'vlan-decap x-y', which succeeds if the packet has
a vlan header in the range x to y, and in this case skips the VLAN header,
tries to re-parse the header fields as in the beginning of
ip_fw_chk() after the section
/*
* Collect parameters into local variables for faster matching.
*/
and then continues.
It's not a lot of code, in the worst case you can just cut&paste
the relevant 50-60 lines from the beginning of the code
(though of course it would be nice to rearrange the code to
reduce duplication).
By doing this you can do something like
ipfw add skipto 1000 vlan-decap 1-50
and then process vlans 1 to 50 at line 1000.
Maybe it is a good idea to split the vlan-id matching and the decapsulation.
cheers
luigi
On Fri, Aug 12, 2005 at 05:07:13AM -0400, Dan Mahoney, System Admin wrote:
> 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 "freebsd-hackers-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050812063359.A14229>