iptables performance

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 <(E-Mail Removed)> writes:

> 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 ?

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?
--
Joseph J. Pfeiffer, Jr., Ph.D. Phone -- (505) 646-1605
Department of Computer Science FAX -- (505) 646-1002
New Mexico State University http://www.cs.nmsu.edu/~pfeiffer
Southwestern NM Regional Science and Engr Fair: http://www.nmsu.edu/~scifair

> 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?

oups . Sorry
I meant 22Mb/s on my LAN . Without iptables i got about 88Mb/s on my
LAN.

On Thu, 09 Oct 2003 07:44:09 +0000, max4 wrote:

>
>> 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?
>
> oups . Sorry
> I meant 22Mb/s on my LAN . Without iptables i got about 88Mb/s on my
> LAN.
Well, gee ........... I guess your packet-filtering works then.

max4 <(E-Mail Removed)> said:
>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 ?

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
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

> 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
well i am usin shorewall version
1.4.6c

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 <(E-Mail Removed)> said:
>> 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
>well i am usin shorewall version
>1.4.6c

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.

>but i must say i have a big blacklist but still it should not be a problem

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.

>i think other firewalls solution can handle this with that kind of cpu.

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.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Juha Laiho <(E-Mail Removed)> wrote in news:bm8ivt$6np$(E-Mail Removed)-
int:

> utilise the record that netfilter keeps about established connections,
> and upon each arriving packet check first whether the packet belongs
>

ok thanks a lot
for the advice
i will check
do u use a frontend ?
what s the best frontend ?

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 <(E-Mail Removed)> said:
>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 ??

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
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# 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.
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)