RE: clarification regarding netgraph and ipfw

From: Alexander Vasenin aka BlackSir (blacksir_at_number.ru)
Date: 07/30/04

  • Next message: D. Pageau: "PXEboot compile error (missing .h)" 
    To: "Glenn Dawson" <glenn@antimatter.net>, <stable@freebsd.org>
Date: Fri, 30 Jul 2004 11:47:13 +0400

    Maybe this is rather crucial solution, but ng_netflow can deal with raw IP (and not only ethernet), so, you can set 'divert' or 'tee' rule for passing traffic from arbitrary place in ipfw to ng_ksocket, which connected to ng_netflow (which export NetFlow through another ng_ksocket). I use tee (with 'tee' patch, described in PR/60377).

    Alexander Vasenin aka BlackSir

    > -----Original Message-----
    > From: owner-freebsd-stable@freebsd.org
    > [mailto:owner-freebsd-stable@freebsd.org]On Behalf Of Glenn Dawson
    > Sent: Friday, July 30, 2004 11:00 AM
    > To: stable@freebsd.org
    > Subject: clarification regarding netgraph and ipfw
    >
    >
    >
    > Greetings,
    >
    > I have a firewall running -STABLE. I'm using ipfw2 for filtering and
    > ng_netgraph (via ng_tee) to export netflow data.
    >
    > According to the man page for ng_ether, the lower hook gets raw ethernet
    > frames as they come off the wire. Reading the man page for ipfw it seems
    > to say that if I turn on net.link.ether.ipfw in sysctl that it will also
    > get things as they come off the wire.
    >
    > So my question is, which one gets them first?
    >
    > The reason I ask is that if I have an ipfw rule to block traffic from an
    > IP, will it get counted by ng_netgraph? Or will ipfw drop the packet
    > before it even gets to ng_ether?
    >
    > If the packets go through ng_ether first and then through ipfw, does anyone
    > know if it's possible to reverse that behavior? I'm doing billing based on
    > traffic and don't want the netflow data to include packets that were
    > dropped by ipfw.
    >
    > Thanks in advance for any insight.
    >
    > -Glenn
    >
    > _______________________________________________
    > freebsd-stable@freebsd.org mailing list
    > http://lists.freebsd.org/mailman/listinfo/freebsd-stable
    > To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
    >

    _______________________________________________
    freebsd-stable@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-stable
    To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"

  • Next message: D. Pageau: "PXEboot compile error (missing .h)"

    Relevant Pages

    • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
      ... For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags. ... Currently the only analyzing node in FreeBSD src tree is ng_bpf, but it merely splits incoming packets in two streams, matched and not. ... There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. ... For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. ...
      (freebsd-current)
    • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
      ... For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags. ... Currently the only analyzing node in FreeBSD src tree is ng_bpf, but it merely splits incoming packets in two streams, matched and not. ... There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. ... For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. ...
      (freebsd-isp)
    • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
      ... For simple using, however, you don't need to bother all that details - just remember magic number and where to place it, and it is now simple for use with ipfw tags. ... Currently the only analyzing node in FreeBSD src tree is ng_bpf, but it merely splits incoming packets in two streams, matched and not. ... There are reasons to this, as netgraph needs to be modular, and each node does a small thing, but does it well. ... For long time ng_bpf was used for another purposes in the kernel, and now, as new ipfw features appeared, ng_tag came up for easy integration. ...
      (freebsd-net)
    • FreeBSD Security Advisory: FreeBSD-SA-01:08.ipfw [REVISED]
      ... included in FreeBSD 4.0 and above. ... based on an old version of ipfw and does not contain as many features. ... Due to overloading of the TCP reserved flags field, ... incorrectly treat all TCP packets with the ECE flag set as being part ...
      (FreeBSD-Security)
    • Re: [PATCH] ng_tag - new netgraph node, please test (L7 filtering possibility)
      ... The problem with pf is that pf compiles all the rules at the time, so exact tags representation can change each time (for this reason ipfw tags were made incompatible with pf), and you must that values to supply them to. ... Also, as it seems non-trivial on current ipfw dynamic rules implementation, I don't know if shaping will work at all. ... But you can try to test such ruleset (it supposes that dynamic rules are checked twice, on incoming packets and on outgoing also, as with all other rules as ipfw manpage says): ...
      (freebsd-current)