iptables performance

Discussion in 'Linux Networking' started by max4, Oct 8, 2003.

  1. max4

    max4 Guest

    I have a linux box with 2 nic
    1 connected to the internet
    1 to my lan 100Mb/s
    on a 1Ghz system

    the problem : iptables is slowing my lan traffic and i only get 22MB/s
    is it a way to optimize iptables rules ?
    Will the new kernel 2.6 improve this ?

    any help welcome
    thank you
    max4, Oct 8, 2003
    1. Advertisements

  2. max4

    Joe Pfeiffer Guest

    Given that a 100Mb/s ethernet should only be providing you with 10
    MB/s half-duplex or 20 MB/s full-duplex, I don't see the problem.

    If you meant 22Mb/s (rather than 22 MB/s), and you're talking about
    traffic going in/out to the internet, that's still a *lot* of
    bandwidth. What has your provider promised you?
    Joe Pfeiffer, Oct 8, 2003
    1. Advertisements

  3. max4

    max4 Guest

    oups . Sorry
    I meant 22Mb/s on my LAN . Without iptables i got about 88Mb/s on my
    max4, Oct 9, 2003
  4. max4

    nunya Guest

    Well, gee ........... I guess your packet-filtering works then.
    nunya, Oct 9, 2003
  5. max4

    Juha Laiho Guest

    There might be a way to optimize the rules -- but we should see your
    rules first to be able to say anything about them. Of course, you can
    go through the rules yourself as well; take a packet of the above
    traffic and start goign through the relevant rule chains to see how
    many comparisions you make before accepting the packet. Think of ways
    to reduce number of those comparisions.

    Some ideas:
    - have a rule "-m state --state RELATED,ESTABLISHED -j ACCEPT"
    somewhere near the very start of your INPUT chain; you may want
    to do some basic sanity checking before this line but not much
    - consider effects of branching your rule chain to lower the
    latency of the opening packet for a given connection
    Juha Laiho, Oct 9, 2003
  6. max4

    max4 Guest

    There might be a way to optimize the rules -- but we should see your
    well i am usin shorewall version

    but i must say i have a big blacklist
    but still it should not be a problem , i think other firewalls solution
    can handle this with that kind of cpu.
    max4, Oct 11, 2003
  7. max4

    Juha Laiho Guest

    Well, shorewall is one utility to create rule sets for the netfilter
    (iptables) functionality. Having never used shorewall, I can't tell
    how good it is in creating even remotely optimal rulesets (or is it
    completely dependent on how you use it).

    So, in the end you anyway have lists of netfilter rules, no matter what
    you use to create the rules. You can create the rules in several ways
    so that the end effect is functionally identical, but with huge variance
    in the induced CPU load.
    Not a problem, but your netfilter configuration can make a huge
    difference. So, if you for each packet first check all your blacklist,
    and only then decide whether you let the packet through, you may be
    doing a huge number of comparisions for each packet. If you instead
    utilise the record that netfilter keeps about established connections,
    and upon each arriving packet check first whether the packet belongs
    to some session that you've already acceped (and thus let the packet
    through without further checks), and only pass the remaining packets
    (those that are starting a new connection) through your blacklist, you
    can see differences in performance. But then, as I don't know how you're
    currently filtering your packets, the only thing I can do is guess.
    With Linux the firewall solution is netfilter - for now (2.4 kernels),
    at least. Then there's a multitude of different (varying in usability
    and quality) frontends to configure it. Or you can also configure it
    without any frontend. However you do, you end up with a set of rules.
    Juha Laiho, Oct 11, 2003
  8. max4

    max4 Guest

    ok thanks a lot
    for the advice
    i will check :)
    do u use a frontend ?
    what s the best frontend ?
    max4, Oct 11, 2003
  9. max4

    max4 Guest

    well you were right
    i asked the guy from shorewall
    and 30 min after the patch was ready :)
    now i finaly have 8MB/s on my lan
    question : if the blacklist is checked for new conexions
    what happen with udp packets ??
    max4, Oct 11, 2003
  10. max4

    Juha Laiho Guest

    Ah, yes. There are connections and connections. Netfilter does maintain
    "connection-like" information for UDP traffic as well. So, if you send
    a UDP packet to some destination, netfilter will for a while (I don't
    actually know for how long) keep the way open for packets coming back the
    same route (so, reversing source and destination IP and port numbers).

    For example, NTP (network time protocol) is built on top of UDP. For
    that I don't have any specific inbound openings (and am currently
    accepting all outbound traffic). For inbound traffic, I have set this
    "allow established and related" rule. When the time server on my machine
    wishes to check the correctness of time from my upstream time server,
    it will send a UDP packet. The response packet (UDP also), is permitted
    because the outbound packet created a "connection" at netfilter level.
    Still, an unsolicited packet from the time server would be blocked.

    The "related" also includes the important ICMP types related to existing
    connections, so when using that there's no necessity to allow any
    specific inbound ICMP, and still you're not breaking your networking
    (as dropping all inbound ICMP would do -- f.ex. you wouldn't get the
    failure information returned by outbound UDP packets which were refused
    by the other party). As ICMP echo (ping) isn't part of any other normal
    protocol communication, allowing "related" will not allow inbound ICMP
    echo, though.

    As to your question in the other message, I'm not using any frontend;
    my rule sets tend to stay rather simple -- and at least for now I believe
    that creating the rulesets in certain structure will keep them simple
    even for rather complicated needs.

    Below is the basic structure I use for my INPUT chain (edited snippet
    from iptables-save output; the INPUT chain policy is DROP):

    # Allow everything from interfaces internal to my network
    -A INPUT -i lo -j ACCEPT
    -A INPUT -i eth0 -j ACCEPT
    # Handle packets by connection state
    -A INPUT -m state --state INVALID -j DROP
    # Handle TCP SYN packets that don't belong to any established session
    # (so, if I'm a target of TCP scan using some other than SYN, those
    # packets don't even enter my tcp-ext processing -- and that's where
    # I have most of my address-based decisions)
    -A INPUT -i eth1 -p tcp -m state --state NEW -m tcp --tcp-flags SYN,RST,ACK SYN
    -j tcp-ext
    # Handle new UDP traffic
    -A INPUT -i eth1 -p udp -m state --state NEW -j udp-ext
    # Handle new ICMP traffic
    -A INPUT -i eth1 -p icmp -m state --state NEW -j icmp-ext
    # Log what was not handled (note: this is the only place where
    # my rulesets log anything)
    -A INPUT -j LOG
    # ... and DROP by chain policy all packets that made it this far

    In tcp-ext chain (a locally created chain that is called from INPUT) I have
    things like:

    # Allow SSH from certain address
    -A tcp-ext -s x.y.z.w -p tcp -m tcp --dport 22 -j ACCEPT
    # Drop tcp/135 traffic (I think this was the Windows RPC port; anyway
    # something I don't want to see in my network -- and something I don't
    # even want into my logs)
    -A tcp-ext -p tcp -m tcp --dport 135 -j DROP
    # Actively reject inbound ident connection attempts from certain address
    -A tcp-ext -s a.b.c.d -p tcp -m tcp --dport 113 -j REJECT --reject-with tcp-reset

    .... so, the above were from a system where no public services are provided
    to the network, so it is set to more or less stealth mode (from outsiders'
    point of view there's nothing responding in any way in this address). I
    believe this greatly reduces the amount of port scans I see. Other reasons
    for not generating responses to unsolicited communications is to keep my
    uplink traffic at a minimum, and also to prevent the use of my machine as
    an attack redirector.
    Juha Laiho, Oct 12, 2003
  11. max4

    max4 Guest

    thanks a lot for all the information :)
    max4, Oct 12, 2003
  12. I remember looking into this when working with TeamSpeak
    (http://www.teamspeak.org/) and I believe UDP "connections" require a
    packet at least every 60 seconds to keep firewalls informed of ongoing
    Kenneth Porter, Oct 13, 2003
  13. I would suggest that the effeciency of operation would be vastly
    improved by putting the ESTABLISHED as the first rule, use -L with -v to
    prove that it is the most used rule, then send all the --syn packets to
    a table, so none of the tests are used for non-syn packets. Then send
    UDP to another table, and ICMP to a third. And look at the number of
    hits to help sort the table and avoid checking rules which don't get
    matched unless the tests must be in some special order.

    I've used firewalls on GigE using this method, and there's next to no
    overhead, because it's all established tcp sockets.

    Hope this helps someone, it's also easier to read later.
    Bill Davidsen, Nov 2, 2003
  14. max4

    Juha Laiho Guest

    Hmm; I agree that your proposal would be a performance improvement -
    but I'm not so confident about the improvement being a "vast" one -
    here we're talking about two very simple and one moderately simple(?)
    comparisions before the ESTABLISHED rule. The lo/eth0 rules (eth0 being
    the interface for my local network) are there for a reason, to avoid the
    netfilter session cache lookup for packets in those interfaces.

    The reason for the INVALID match to be before the ESTABLISHED match is
    to drop as much of known bad traffic as soon as possible - and I rather
    have these two rules ordered this way, to keep "crap" from entering the

    If my rule ordering were for example so that I do a pile of TCP SYN
    matches, verifying source and destination addresses (or rather,
    networks), and only just before failing completely did check the
    ESTABLISHED rule, then I'd understand your critique (or rather, if
    my rule ordering was such, I guess I wouldn't be capable to understand
    your critique), but as I don't see any huge difference in our proposed
    setups, I don't understand your rationale.
    Yep, as was in my text as well. But here again I'm rather confident
    that with any near-current hardware the optimal ordering of the rules
    is playing the game of diminishing returns. As you say, most of the
    traffic is passed by the ESTABLISHED rule anyway, so sorting these
    rules only affect the packets that are attempting to establish a new
    netfilter session. Here I seem to have roughly a ratio of 1000:1 with
    the packets matched by the ESTABLISHED rule against the packets gone
    to the TCP chain for processing. With these kinds of situations it
    hardly pays off to spend any time to optimising that 1/1000 - unless
    the part that handles that 1/1000 was deliberately badly written.

    As for ratios, here I seem to have roughly 1:1 packet ratio on my "local
    interface" rule and the ESTABLISHED rule, so most of the traffic matched
    by interface is then off from loading the connection lookup mechanism -
    as matching by interface definitely is faster than looking through
    some session cache (even though at least in my case the connection
    table size is typically very small).
    It would be interesting to hear benchmark results from that kind of
    systems about the difference you could see on them by adding even two
    dummy interface rules on them before the ESTABLISHED rule. My guess
    is that there is no measurable difference (i.e. that the negative
    matches on those are fast enough not to be a consequence).

    What kind of system buses do you have on those GigE fw systems, btw?
    Juha Laiho, Nov 3, 2003
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.