IP Tables slows network response times

IP Tables slows network response times

[Michael Hallager]

Hello all.

I have spent rather a lot of time trying to find an answer for this one.

I have a Slackware Linux box, 2.4.29 kernel running IP Tables. I have the bare 
number of needed modules compiled into the custom kernel.

I start IP Tables using the following batch file:

iptables -P INPUT DROP
iptables -A INPUT -p tcp --destination-port 22 -j ACCEPT
iptables -A INPUT -p tcp --destination-port 25 -j ACCEPT
iptables -A INPUT -p tcp --destination-port 53 -j ACCEPT
iptables -A INPUT -p udp --destination-port 53 -j ACCEPT
iptables -A INPUT -p tcp --destination-port 80 -j ACCEPT
iptables -A INPUT -p tcp --destination-port 110 -j ACCEPT
iptables -A INPUT -p tcp --destination-port 443 -j ACCEPT

This works except it makes webpages and email served from this box SLOW to 
respond. (Several seconds).

Any ideas please? Questions welcomed.

Michael Hallager
networkStuff ltd
www.networkstuff.co.nz | p.09.839.1000 | m.029.638.7883

Re: IP Tables slows network response times

[Eric Leblond]

[-- Attachment #1: Type: text/plain, Size: 770 bytes --]

On Sun, 2005-08-14 at 21:33 +1200, Michael Hallager wrote:
> Hello all.
> 
> I have spent rather a lot of time trying to find an answer for this one.
> 
> I have a Slackware Linux box, 2.4.29 kernel running IP Tables. I have the bare 
> number of needed modules compiled into the custom kernel.

> This works except it makes webpages and email served from this box SLOW to 
> respond. (Several seconds).
> 

several seconds ? looks like you've got a timeout problem on name
resolution (or another network access). Please ensure that DNS or name
resolution traffic is not blocked.
More over, add a rule to accept loopback traffic on INPUT, blocked
loopback traffic could explain problem you have.

Hope this help,
-- 
Eric Leblond <eric@inl.fr>
INL

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: IP Tables slows network response times

[Michael Hallager]

Hi Eric.

Don't think so, I fixed the reverse DNS issue earlier:
root@202-150-101-225:/usr/local/Dialect/PaymentClient/config# nslookup 
202.150.101.225
Server:         202.150.101.225
Address:        202.150.101.225#53

225.101.150.202.in-addr.arpa    name = 202-150-101-225.networkstuff.net.nz.

root@202-150-101-225:/usr/local/Dialect/PaymentClient/config# 

This machine runs its own DNS server.

> several seconds ? looks like you've got a timeout problem on name
> resolution (or another network access). Please ensure that DNS or name
> resolution traffic is not blocked.
> More over, add a rule to accept loopback traffic on INPUT, blocked
> loopback traffic could explain problem you have.

Could you please provide a sample of this rule?
-- 
Michael Hallager
networkStuff ltd
www.networkstuff.co.nz | p.09.839.1000 | m.029.638.7883

RE: IP Tables slows network response times

[Gary W. Smith]

Something like the following (off the top of my head, so syntax may not
be exact)

iptables -I INPUT -o lo -j ACCEPT
iptables -I FORWARD -o lo -j ACCEPT
iptables -I OUTPUT -o lo -j ACCEPT

Basically, tell the server to allow anything originating from loopback

> -----Original Message-----
> From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> bounces@lists.netfilter.org] On Behalf Of Michael Hallager
> Sent: Sunday, August 14, 2005 2:55 AM
> To: Eric Leblond; netfilter@lists.netfilter.org
> Subject: Re: IP Tables slows network response times
> 
> Hi Eric.
> > More over, add a rule to accept loopback traffic on INPUT, blocked
> > loopback traffic could explain problem you have.
> 
> Could you please provide a sample of this rule?
> --
> Michael Hallager
> networkStuff ltd
> www.networkstuff.co.nz | p.09.839.1000 | m.029.638.7883

Re: IP Tables slows network response times

[Nikolai Geogriev]

I think correct should be:
itpables -I INPUT -i lo -j ACCEPT (guess you misspeled it in the hurry)
forward rule for loopback is not necesary, as long as i remember
iptables -I OUTPUT -o lo -j ACCEPT;


On 8/14/05, Gary W. Smith <gary@primeexalia.com> wrote:
> Something like the following (off the top of my head, so syntax may not
> be exact)
> 
> iptables -I INPUT -o lo -j ACCEPT
> iptables -I FORWARD -o lo -j ACCEPT
> iptables -I OUTPUT -o lo -j ACCEPT
> 
> Basically, tell the server to allow anything originating from loopback
> 
> > -----Original Message-----
> > From: netfilter-bounces@lists.netfilter.org [mailto:netfilter-
> > bounces@lists.netfilter.org] On Behalf Of Michael Hallager
> > Sent: Sunday, August 14, 2005 2:55 AM
> > To: Eric Leblond; netfilter@lists.netfilter.org
> > Subject: Re: IP Tables slows network response times
> > 
> > Hi Eric.
> > > More over, add a rule to accept loopback traffic on INPUT, blocked
> > > loopback traffic could explain problem you have.
> > 
> > Could you please provide a sample of this rule?
> > --
> > Michael Hallager
> > networkStuff ltd
> > www.networkstuff.co.nz | p.09.839.1000 | m.029.638.7883
> 
> 
>

Re: IP Tables slows network response times

[Grant Taylor]

I've not run in to or heard of this problem my self before.  But I suspect that there is a support protocol being used that we are aware of.  How knows you may have a few things configured to use the Ident (Auth) protocol to find out the name of the user on the system that is requesting the web pages from.  If this is indeed the case and you do not have a statefull packet inspection allowing returning outbound traffic back in you may be dropping some returning traffic that is sent out from a high port.  In either case I would add the following rules to the end of your list to help diagnose this problem.

iptables -A INPUT -p tcp -m state --state ESTABLISHED -j ACCEPT
iptables -A INPUT -p tcp -j LOG

The second rule is probably the most important as it will log the traffic that is getting dropped and thus you will have an idea what you need to modify your firewall to allow in.



Grant. . . .

Michael Hallager wrote:
> Hello all.
> 
> I have spent rather a lot of time trying to find an answer for this one.
> 
> I have a Slackware Linux box, 2.4.29 kernel running IP Tables. I have the bare 
> number of needed modules compiled into the custom kernel.
> 
> I start IP Tables using the following batch file:
> 
> iptables -P INPUT DROP
> iptables -A INPUT -p tcp --destination-port 22 -j ACCEPT
> iptables -A INPUT -p tcp --destination-port 25 -j ACCEPT
> iptables -A INPUT -p tcp --destination-port 53 -j ACCEPT
> iptables -A INPUT -p udp --destination-port 53 -j ACCEPT
> iptables -A INPUT -p tcp --destination-port 80 -j ACCEPT
> iptables -A INPUT -p tcp --destination-port 110 -j ACCEPT
> iptables -A INPUT -p tcp --destination-port 443 -j ACCEPT
> 
> This works except it makes webpages and email served from this box SLOW to 
> respond. (Several seconds).
> 
> Any ideas please? Questions welcomed.
> 
> Michael Hallager
> networkStuff ltd
> www.networkstuff.co.nz | p.09.839.1000 | m.029.638.7883

Re: IP Tables slows network response times

[Jan Engelhardt]

>iptables -P INPUT DROP
>iptables -A INPUT -p tcp --destination-port 53 -j ACCEPT
>iptables -A INPUT -p udp --destination-port 53 -j ACCEPT

"Think before you rule."

If your NAMED makes a query to the outside world, its _DEFAULT configuration 
will NOT use_ 53 as source port, so --destination-port 53 cannot match.

(Use -m state --state ESTABLISHED)

Fwd: Re: IP Tables slows network response times

[Michael Hallager]

> I think correct should be:
> itpables -I INPUT -i lo -j ACCEPT (guess you misspeled it in the hurry)
> forward rule for loopback is not necesary, as long as i remember
> iptables -I OUTPUT -o lo -j ACCEPT;

HOLD ON,
This creates the following:
chain INPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere
DROP       all  --  202.71.136.166       anywhere

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
ACCEPT     all  --  anywhere             anywhere

Looking at the first and last rule displayed here, dosn't this have the effect 
of negating everything else?
Eg: Allow all, from anywhere to anywhere....

Am I missing something?

Michael Hallager
networkStuff ltd
www.networkstuff.co.nz | p.09.839.1000 | m.029.638.7883

Re: Fwd: Re: IP Tables slows network response times

[Jörg Harmuth]

Michael Hallager schrieb:
>>I think correct should be:
>>itpables -I INPUT -i lo -j ACCEPT (guess you misspeled it in the hurry)
>>forward rule for loopback is not necesary, as long as i remember
>>iptables -I OUTPUT -o lo -j ACCEPT;
> 
> 
> HOLD ON,
> This creates the following:
> chain INPUT (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  anywhere             anywhere
> DROP       all  --  202.71.136.166       anywhere
> 
> Chain FORWARD (policy ACCEPT)
> target     prot opt source               destination
> 
> Chain OUTPUT (policy ACCEPT)
> target     prot opt source               destination
> ACCEPT     all  --  anywhere             anywhere
> 
> Looking at the first and last rule displayed here, dosn't this have the effect 
> of negating everything else?
> Eg: Allow all, from anywhere to anywhere....
> 
> Am I missing something?

Yes, -v ;) Ok, you certainly typed "iptables -L" and this will not
output the interfaces. Try "iptables -nvL" and you will see, that
"ACCEPT all anywhere anywhere" concerns only loopback.

Regarding the timeout issue, do as Grant recommended. May be you should
log in OUTPUT too, at least if logging in INPUT will not show the problem.

Have a nice time,

Joerg

Re: Fwd: Re: IP Tables slows network response times

[Michael Hallager]

Thankyou :-)

I am in the middle of recompiling my kernel for IP Tables logging support.

> Regarding the timeout issue, do as Grant recommended. May be you should
> log in OUTPUT too, at least if logging in INPUT will not show the problem.
>
> Have a nice time,
>
> Joerg

-- 
Michael Hallager
networkStuff ltd
www.networkstuff.co.nz | p.09.839.1000 | m.029.638.7883

Re: Fwd: Re: IP Tables slows network response times

[/dev/rob0]

On Monday 2005-August-15 04:32, Jörg Harmuth wrote:
> > Am I missing something?
>
> Yes, -v ;) Ok, you certainly typed "iptables -L" and this will not
> output the interfaces. Try "iptables -nvL" and you will see, that
> "ACCEPT all anywhere anywhere" concerns only loopback.
>
> Regarding the timeout issue, do as Grant recommended. May be you
> should log in OUTPUT too, at least if logging in INPUT will not show
> the problem.

GMTA. :) I just sent something very much like the foregoing, except due 
to a MUA/PEBKAC problem I missed the fact that it went offlist. The one 
substantive addition in my offlist message was a recommendation to use 
iptables-save(8) output to see a detailed listing of rules.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Fwd: Re: IP Tables slows network response times

[/dev/rob0]

On Monday 2005-August-15 04:45, Michael Hallager wrote:
> I am in the middle of recompiling my kernel for IP Tables logging
> support.

In the OP you mentioned that this is Slackware. Whilst there are 
numerous good reasons why one might wish to compile a custom kernel, 
it's worthy of note that the Slackware stock kernels as configured 
"Just Work" perfectly with iptables.

The best Slackware advice I have is to start with Pat's config for the 
basis for your new kernel. Second best: just use his kernel and 
modules. Slackware-current has 2.4.31, and those packages will work 
seamlessly in any 2.4.x-capable Slackware release (that's 8.0 and 
later. And don't forget the alsa-driver package.)

I generally only compile custom kernels for high-end machines, like 
those with RAM >= 1GB, or SMP.
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header

Re: Fwd: Re: IP Tables slows network response times

[Michael Hallager]

1. I have tried both IN and OUT and I am not seeing any error messages or 
anything *obvious*

2. With those FW rules in place I can do NSLOOKUP on the domain anme with no 
problems.

> Regarding the timeout issue, do as Grant recommended. May be you should
> log in OUTPUT too, at least if logging in INPUT will not show the problem.
>
> Have a nice time,
>
> Joerg

-- 
Michael Hallager
networkStuff ltd
www.networkstuff.co.nz | p.09.839.1000 | m.029.638.7883

Re: Fwd: Re: IP Tables slows network response times

[Michael Hallager]

> The best Slackware advice I have is to start with Pat's config for the
> basis for your new kernel. Second best: just use his kernel and
> modules. Slackware-current has 2.4.31, and those packages will work
> seamlessly in any 2.4.x-capable Slackware release (that's 8.0 and
> later. And don't forget the alsa-driver package.)

The original reason is that it is an IBM Netfinity with a SCSI RAID 
controller.

This is somewhere I would prefer not to go at present as the machine is 
located at almost the other end of the country.

That is why I keep recompiling 2.4.29, the one I originally compiled for this 
machine, rather then upgrading. There is only a small chance that something 
would go wrong but I prefer not to give Murphey a chance....

Please advise if you think there is any not so obvious options needed.

I have read several 'howtos' and official DOC's when setting IP Tables up.

Michael Hallager
networkStuff ltd
www.networkstuff.co.nz | p.09.839.1000 | m.029.638.7883

Re: Fwd: Re: IP Tables slows network response times

[Jörg Harmuth]

Michael Hallager schrieb:
> 1. I have tried both IN and OUT and I am not seeing any error messages or 
> anything *obvious*
> 
> 2. With those FW rules in place I can do NSLOOKUP on the domain anme with no 
> problems.

Humm, strange. Could you please provide the output of iptables-save as
Rob said ?

Some time ago, I had a similar problem with slow responses (~30s delay).
It turned out that it was identd, as Grant assumed in your case too.
Adding a rule like

iptables -A OUTPUT -p tcp --dport 113 -j REJECT \
         --reject-with tcp-reset

solved this for me. I don't know the Slackware distro, but it seems,
that they use sendmail. If this is true, it is quite likely that identd
causes the trouble (at least it was true for me on one box).

Have a nice time,

Joerg

Re: Fwd: Re: IP Tables slows network response times

[Michael Hallager]

I use Postfix MTA and I am getting long waits on other aservices like www.
I will post the output.

> Some time ago, I had a similar problem with slow responses (~30s delay).
> It turned out that it was identd, as Grant assumed in your case too.
> Adding a rule like
>
> iptables -A OUTPUT -p tcp --dport 113 -j REJECT \
>          --reject-with tcp-reset
>
> solved this for me. I don't know the Slackware distro, but it seems,
> that they use sendmail. If this is true, it is quite likely that identd
> causes the trouble (at least it was true for me on one box).
>
> Have a nice time,
>
> Joerg

-- 
Michael Hallager
networkStuff ltd
www.networkstuff.co.nz | p.09.839.1000 | m.029.638.7883

Re: Fwd: Re: IP Tables slows network response times

[/dev/rob0]

On Monday 2005-August-15 05:05, Michael Hallager wrote:
> > Regarding the timeout issue, do as Grant recommended. May be you
> > should log in OUTPUT too, at least if logging in INPUT will not
> > show the problem.
> >
> 1. I have tried both IN and OUT and I am not seeing any error
> messages or anything *obvious*

Your "dmesg" output is likely now full of dropped packet logging. 
Assuming Slackware's syslogd configuration, the same packet logs will 
be found in /var/log/syslog. Those packets tell the story of what is 
being dropped.

On Monday 2005-August-15 05:10, Michael Hallager wrote:
> > modules. Slackware-current has 2.4.31, and those packages will work
> > seamlessly in any 2.4.x-capable Slackware release (that's 8.0 and
> > later. And don't forget the alsa-driver package.)
>
> The original reason is that it is an IBM Netfinity with a SCSI RAID
> controller.

No doubt one of the stock .s kernels, probably raid.s, supports this 
controller.

> This is somewhere I would prefer not to go at present as the machine
> is located at almost the other end of the country.

Remote reboots are always risky. It helps immensely if there is a 
console and a warm body nearby.

I avoid unattended remote reboots as much as possible, but there are 
things you can do to minimise the risk. lilo(8) has a one-time reboot 
option. You can use that to boot into a test kernel, and have a cron or 
at(1) job set to reboot. If all is working you can log in and cancel 
the scheduled reboot.

Of course that fails if the OS fails to load, or if the kernel is 
severely lacking what might be needed, but this is highly unlikely if 
you're testing a Slackware kernel.

> That is why I keep recompiling 2.4.29, the one I originally compiled
> for this machine, rather then upgrading. There is only a small chance

The version is a minor issue at most, especially with late-model 2.4.x 
releases. 2.4 has been stable for quite some time. The major issue is 
the configuration of the kernel,

> that something would go wrong but I prefer not to give Murphey a
> chance....

Of course if you can get by with just a modules recompile, do so.

> Please advise if you think there is any not so obvious options
> needed.

See /boot/config. No, I couldn't guess what specific options you might 
be missing.

> I have read several 'howtos' and official DOC's when setting IP
> Tables up.

None I have seen explain the problems of using kernel default settings. 
That is why I have always recommended starting with Slackware defaults. 
I'm loosely affiliated with slackbook.org, which in Slackware terms is 
a semi-official documentation project. I will talk to Alan and propose 
a rewrite of http://slackbook.org/html/system-configuration-kernel.html 
to include this explanation.

On Monday 2005-August-15 06:07, Michael Hallager wrote:
> AS FOLLOWS:
>
> root@202-150-101-225:/home/michael# iptables-save

There are no rules whatsoever! Did you or some process flush them?
-- 
    mail to this address is discarded unless "/dev/rob0"
    or "not-spam" is in Subject: header