[Soekris] net4801 bridging firewalls benchmarks results

Sat Oct 8 21:26:32 UTC 2005

2005/10/8, Jason Dixon <jason at dixongroup.net>:
> On Oct 8, 2005, at 12:34 PM, Giovanni Faglioni wrote:
> I like the idea of your tests, but why not throw up a page with
> complete results?

     We do not have a company website yet. :(
     We're in "startup mode" and our priorities are
     to get the products ready. :)

> Showing the throughput of the various systems with
> firewall enabled, but no filter rules, doesn't really give any useful
> information.

    The aim of our tests was to evaluate the speed of various
    sistems in a "best case" scenario:

    We assumed that a filter with few rules is faster than a
    more complex one. (it is possible that we guessed wrong, but
    I think that a system that processes 40Mib/sec with
    a very simple filter is very likely to be slower than that with
    more complex ones.)

    So we did not test these cases, albait we have
    no data to support this assumption.

    We just said that it was _not_ a very scientific way of doing tests... ;)

> If you're not going to use any filter rules, then at
> least have the packet filters disabled.

      We have some results for this case:

      OpenBSD is still the slower one (between 32 and 38Mib/sec, if I recall
      correctly) and Linux 2.4 goes full speed (93Mib/sec). We did not
      test Linux 2.6 and FreeBSD 6. (I assume that FreeBSD 4.9 works
      full speed. If it doesn't: enable the firewall and it will. :)

> On the other hand, I would
> be interested in seeing some numbers with "basic" real-life examples
> (say, traffic inbound to a DMZ... or traffic outbound from a LAN).

    We use a novell (to us) approach to DMZs: each and every server has
    his own one, and each DMZ has a reverse firewall that protects the
    internet _from_ the server (in addition to the usual firewall that protects
    the server from the Internet).
    We permit outbound traffic from each server in a very limited way, and
    log each and every violation of the policy.

    As an example, our webserver can talk only to our DNS servers at the
    DNS ports, to our NTP servers at the NTP ports and every other traffic
    triggers an alarm. (some icmp types are excluded, so that Path MTU
    discovery, source-quench etc. etc. do work correctly)
    The responses to the http queries are handled by the stateful inspection
    rules.

    We call this setup an "Ivory Tower".
    (well, a real Ivory Tower has some means to disable the outbound firewall
    to make maintainance possible, in a "shields-off" configuration, but that's
    another story)

    The beauty of this solution is that every oubound (from the DMZs point
    of view) policy violation is a real violation, (no more tons of junk alerts
    nobody can act upon), and the eventual {virus,worm,hacker} is caught
    at the first (denied) packet it produces.
    It also makes for a very good network documentation. :)

    We are not interested in other setups as of now, 'cause our
    resources are _very_ limited. We're a two people company. :)

> P.S.  I'm very impressed/skeptical of the FreeBSD 4.9 wire-speed
> results.

   We were too, but the results are easily replicable to anyone interested:
   it suffices to go to the m0n0bsd website (http://www.m0n0.ch, these
   '0' are numbers, not letters), grab the correct soekris CompactFlash
   image and install it.

   Our bridging firewall setup is:
sysctl net.link.ether.bridge=1
sysctl net.link.ether.bridge_cfg=sis0,sis1,sis2,sis3,sis4,sis5,sis6
sysctl net.link.ether.bridge_ipf=1
sysctl net.link.ether.ipfw=0

   Our "0 rules" ipfilter is:
#
# this is to enshure ssh access
#
pass  in  quick proto tcp  from 10.1.1.59  to 10.1.1.60 port = 22 keep state
#
# just to test that the firewall filters..
# no traffic to the Asterisk PBX
#
block in  quick on sis5 from any to 10.1.1.20

pass in  quick all
pass out quick all

   Put those rules in a file (say test-ipf.conf) and activate
   them with ipf -Fa -f ./test-ipf.conf

   The setup for netserver/netperf we used is quite simple:
   launch netserver on both PCs and use:
   netperf -H <Other_host_IPAddress> -l 60
   (one at a time) to get a bandwith estimation.

   In our tests, these estimate were quite good, id est: we experienced
   similar performances with file transfers from ramdisk to ramdisk.
   (something like 11.6MiB/sec wich is about 92.8Mib/sec)

> P.P.S.  I'm not surprised by the OpenBSD speeds;  I believe the
> OpenBSD sis driver still has issues.  I have no evidence to back this
> up, just anecdotal evidence (the maxxed out irq's, for one).

   Yes, I agree. The natsemi FreeBSD driver makes the difference,
   by switching to polling mode after a second or two of high
   irq load. OpenBSD doesn't have polling mode. Linux does,
   but I believe that it is not enabled/developed for the natsemi
   DP83815 chipset. (maybe I'm wrong, and it's easily enabled.
   If someone just knows how to do it, I'll appreciate if (s)?he does
   give some hints to us: we're still in evaluation mode)

--

   --Giovanni Faglioni