I have a problem with iptables on redhat 7.3.
My rules seems to work OK, but fantastically slowly.
No troubles with ACCEPT (of course?), and enough
packets get through to show that the rules are working.

This happens on two similarly configured machines. Both have
a second network card (inactivated on one). Since I actually
do the serving and routing on these machines using a Java server,
I didn't intend to set up masq.

The conventional wisdom with such problems seems to be that
DNS lookups are taking the time, but why in my case(s) I don't see.

Also discovered that I need to allow -i lo, which I think I have done
(see below) but ...

On one of these machines ipchains worked OK, with Redhat 6.2.

What obvious thing have I missed?

iptables -P INPUT DROP
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
# allow dns lookups (my Java server does dns!)
iptables -A INPUT -p udp --dport 53 -s 210.0.0.0 -i eth0 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -i eth0 -j ACCEPT

thanks

My first port of call would be this :

>allow dns lookups (my Java server does dns!)

*blink* I'm confused - you have a java dns server? I would think this is a monumental waste of resources and if I were getting slow dns lookups would look here first...

Can you provide a bit more info, I'm desperately confused about what it is you have running here. I don't immediately see anything wrong with the rules...

Slick.

Thanks.
Agreed this is awfully nonstandard. The java server exists because it gives cross-platform services. I just happen now to be running it on linux as well
as macos and windows. It is doing the http for the test of the rules. It does
dns too, but I am not (yet) testing it because the connections on udp:53
aren't getting through, or at least most of them aren't.
So let me clarify a bit. My server happens to do dns, which is why I open 53,
but this is lightning fast for ACCEPT policy, so it shoudn't have anything to
do with the slow DROP policy setting.
By the way, one of these two servers runs an SAP WAS allowed by the rule:
#iptables -A INPUT -p tcp --dport 3200:3299 -j ACCEPT
which sings with ACCEPT policy and dies wih DROP.
So I doubt that the problem is connected with the Java, unless indirectly
from the -i lo, but then I don't get it ...

Oky... So, your ACCEPT's are fine, but your DROP's are slow?

What are you dropping?
Can you give an example of what works well, and what is really slow?

Slick.

Good question Slick. Thanks.

I had thought that *everything* was slow, until I discovered yesterday that the SAP WebApplicationServer, which was fast on ACCEPT, was also fast on DROP. I discovered that my etc/hosts file had an error in it, which strangely (to me!) only affects performance when DROP is policy. (Why is this?) So
then I added explicit ICMP rules (see below for the latest iptables) and found that these are also fast with DROP.
So now I have reached the depressing truth! It is ONLY my Java server (serving tcp:80 and udp:53 for now) which is slow with DROP (though faster than Apache and BIND for ACCEPT).
So actually this thread turns out perhaps to be about Java and iptables (and multiples interfaces?).

Not sure where to go now. One of these servers is running against the Sun jre, the other against the IBM jre (two boxes!). I have a hunch that the second network card is stuffing up the Java on DROP policy, partly because this sometimes happens even on ACCEPT (ie before I added iptables), though I have usually been able to fix this by inactivating the card. I also suspect that DROP forces a use of /etc/hosts which is causing a delay, but I haven't worked out how to fix this (current etc/hosts added below). Must hosts deal somehow with eth1?

Interesting problem!

Thanks for your trouble.

iptables -P INPUT DROP

iptables -A INPUT -p icmp --icmp-type 0 -i eth0 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 3 -i eth0 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 8 -i eth0 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 11 -i eth0 -j ACCEPT
iptables -A INPUT -p icmp --icmp-type 30 -i eth0 -j ACCEPT
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
iptables -A INPUT -p tcp --dport 80 -i eth0 -j ACCEPT
#SAP WAS
iptables -A INPUT -p tcp --dport 3200:3299 -i eth0 -j ACCEPT
#strix special data transfer protocol
iptables -A INPUT -p tcp --dport <xxx> -i eth0 -j ACCEPT
#strix dns
iptables -A INPUT -p udp --dport 53 -i eth0 -j ACCEPT

# Do not remove the following line, or various programs
# that require network functionality will fail.
127.0.0.1 localhost
<x.x.x.x> strixsap strixsap.thestrix.net

Best you take a good look at what is being dropped once it reaches the end of the rules...

With an ACCEPT policy, it is accepted if none of the rules match,
and similar with the DROP policy, it gets dropped if no rules match.

Add some logging to the end of the rules eg
iptables -A INPUT -j LOG --log-prefix "to be dropped "
then do tail -f /var/log/messages to watch the entries with a DROP policy.
This will tell you what needs to be fine tuned in your rules...

Thanks Peter

But I think I have actually misconstructed the problem here.
These rules work exactly as they should. They drop whatever and
accept whatever as they should.
The problem is: if the accepted port is served by my Java server (now
tcp:80 and udp:53), the service is too slow and times out.
This even though tcp:80 with accept policy is blisteringly quick.
And other services not provided by my Java server (eg tcmp)
work normally for both policies.
So it's actually a Java issue, not an iptables issue, other than
indirectly. For some reason, when I run the Java
server with drop policy, it slows to a crawl.
The server times out
on some (background) task or other engendered by drop policy, which it doesn't do on accept policy.
I have a hunch this is connected with the (unused) second network card.

Does that clarify it at all?

Cheers

Thanks Peter

But I think I have actually misconstructed the problem here.
These rules work exactly as they should. They drop whatever and
accept whatever as they should.
The problem is: if the accepted port is served by my Java server (now
tcp:80 and udp:53), the service is too slow and times out.
This even though tcp:80 with accept policy is blisteringly quick.
And other services not provided by my Java server (eg tcmp)
work normally for both policies.
So it's actually a Java issue, not an iptables issue, other than
indirectly. For some reason, when I run the Java
server with drop policy, it slows to a crawl.
The server times out
on some (background) task or other engendered by drop policy, which it doesn't do on accept policy.
I have a hunch this is connected with the (unused) second network card.

Does that clarify it at all?

Cheers

Yes, I can see your thinking...

But what I'm suggesting is to prove that the rules are ok.
The only difference between a drop policy and an accept policy is what happens if a packet reaches the bottom of the chain... it hasn't matched any of the rules if it gets to the end of the chain. The accept policy lets it pass and a drop policy chews it.

So we know packets are getting chewed by the drop policy,
Hence the adding a -j LOG line and having a look for it.

Thanks Peter.

Done as you suggest.
The result is that the usual suspects are reaching the bottom of the chain
and getting dropped (eg DHCP, some taps and 110, which I have not allowed).
tcp:80 and udp:53 are NOT being dropped, (nor ICMP).
But these services provided by my java server continue to
be extremely slow when policy is DROP, though they get done
eventually (dns times out, but http arrives at the browser sooner or
later).

So I remain convined that this is a java question.
In which case, I feel I should restart it as such, since it doesn't seem
to be about iptables after all, other than indirectly.

Is there a good linux way of finding out what the system is doing for
20 secs before it responds? Might I have a thread problem which for
some reason only happens when DROP is on?

Don't know what to do now ...

Btw Peter

I wonder about
>>So we know packets are getting chewed by the drop policy,
>>Hence the adding a -j LOG line and having a look for it.

The actual problem is not the x-client times out because relevant
packets are denied. The packets for say tcp:80 are ACCEPTED
(your suggested LOG has proved that). It's just that under DROP they
take forever to get served.

Regards

So the server is busy doing something that a drop policy denies it to do.
My instant suspicion is either a dns reply from validating a page address or an icmp reply to say something didn't work.

I would start by isolating each protocol one by one, eg 'iptables -I INPUT -p ! tcp -j ACCEPT' to isolate the tcp protocol as the problem.

That will place the rule at the beginning of the chain, & 'iptables -D INPUT 1' will remove it.
Do this for udp, tcp and icmp and see which one corrects the speed issue.
Then make more specific rules to isolate it further, eg
iptables -I INPUT -p udp -m state --state ESTABLISHED,RELATED -j ACCEPT

What have you got in the rest of the ruleset? OUTPUT chain etc?

Peter

Many thanks for all your help with this.
It seems to be fixed. <->
I took your advice exactly.
iptables -I INPUT ! tcp -j ACCEPT fixed it.
! udp didn't
! icmp fixed it.
So I did the obvious
iptables -I INPUT udp -j ACCEPT, which fixed it.

So we logged udp, found the traffic involved,
then selected traffic by rule to see how it was fixed.
(Not quite, since the first try worked).
We added the rule:
iptables -A -udp --sport 53 -i eth0 -s 192.x.x.0/24 -j ACCEPT
(192.x.x.y and z are the two building dns servers!!!!!)

Very pleased that my problems aren't with the Java.

Thanks again