Re: ipfw rules vs routes to localhost?

From: Crist J. Clark (crist.clark_at_attbi.com)
Date: 05/28/03

  • Next message: Julian Elischer: "Re: Linkproof or Fatpipe with FreeBSD?" 
    Date: Wed, 28 May 2003 14:03:59 -0700
To: Paul Chvostek <paul@it.ca>

    On Wed, May 28, 2003 at 12:51:54AM -0400, Paul Chvostek wrote:
    >
    > I'm considering:
    >
    > ipfw add N deny ip from a.b.c.d to any
    >
    > vs.
    >
    > route add -host a.b.c.d localhost
    >
    > I need to block traffic to a number of IP addresses. I thought I'd use
    > ipfw to avoid things like UDP DNS lookups that might come in ant take up
    > resources while my system tried to respond, but it's been suggested on
    > another list that setting routes to localhost will use less resources.
    > Ideally, I'd like to be able to block a few tens of thousands of IPs.
    >
    > What's the scoop?

    Someone is assumng the old rule for blocking traffic on a (Cisco)
    router applies to the FreeBSD stack. It doesn't necessarily apply.

    First off, blocking it in ipfw rules is obviously more efficient if
    you are running ipfw(8) already.

    If you wouldn't be otherwise running ipfw(8) at all, there _may_ be
    some gain. Packets blocked by ipfw(8) get dropped very early in
    ip_input(), which is good, but _all_ packets have to go through
    ipfw(8), and we usually assume the majority of packets are "good"
    ones. So, the second case, adding the route, doesn't add much overhead
    to the processing of good packets, but does greatly increase the
    resources used before you toss out bad ones. You may end up using
    fewer resources if there are only a few bad ones relative to the
    good.

    IMHO, if this machine is a firewall, use the right tool for
    firewalling, ipfw(8). Are you short on resources in the first place?
    If you are really pushing this machine's routing capabilities to its
    max, you might be in need of an OS and hardware designed solely for
    routing. Tinkering with ipfw(8) versus blackhole routes probably is
    not the way to solve the problem. 

    -- 
Crist J. Clark                     |     cjclark@alum.mit.edu
                                   |     cjclark@jhu.edu
http://people.freebsd.org/~cjc/    |     cjc@freebsd.org
_______________________________________________
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@freebsd.org"
  • Next message: Julian Elischer: "Re: Linkproof or Fatpipe with FreeBSD?"

    Relevant Pages

    • Re: ipfw rules vs routes to localhost?
      ... want to add the "-blackhole" modifier so that the packets are dropped ... Otherwise they would unnecessarily go up the stack ... >> another list that setting routes to localhost will use less resources. ...
      (freebsd-net)
    • 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)