5.4 -- bridging, ipfw, dot1q

From: Dan Mahoney, System Admin (danm_at_prime.gushi.org)
Date: 08/12/05

  • Next message: Eric Anderson: "Re: gjournal public alpha release"
    Date: Fri, 12 Aug 2005 05:07:13 -0400 (EDT)
    To: hackers@freebsd.org
    
    

    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"
    

  • Next message: Eric Anderson: "Re: gjournal public alpha release"

    Relevant Pages

    • Re: 5.4 -- bridging, ipfw, dot1q
      ... The packets you see are encapsulated in 802.1q aka VLAN frames, ... > assume the bridge at least sees the packets). ... > My only guess is that ipfw doesn't have the brains to look beyond the VLAN ...
      (freebsd-hackers)
    • Re: ipfw fwd layer2/ftp proxy
      ... I'm having trouble allowing ftp connections through ipfw enabled bridge firewall. ... I thought of forwarding packets in layer2, however it seems like ipfw still doesn't support that. ...
      (freebsd-net)
    • Re: ipfw fwd layer2/ftp proxy
      ... I'm having trouble allowing ftp connections through ipfw enabled bridge firewall. ... I thought of forwarding packets in layer2, however it seems like ipfw still doesn't support that. ...
      (freebsd-net)
    • Re: 5.4 -- bridging, ipfw, dot1q
      ... Packet counts work (so I assume the bridge at least sees ... In the ipfw rule in question ... it seems only the kernel has an issue. ... "Okay, ...
      (freebsd-questions)
    • Re: [5.2.1-RC, IPFW] Traffic Shaping
      ... *)when I say tried I really mean ipfw didnt complain, ... > The bridge is setup between a router and an internal mail server. ...
      (freebsd-questions)