Fwd: Re: IP Tables slows network response times

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

[Michael Hallager]

AS FOLLOWS:

root@202-150-101-225:/home/michael# iptables-save
# Generated by iptables-save v1.3.3 on Mon Aug 15 23:04:03 2005
*mangle
:PREROUTING ACCEPT [23057:1705962]
:INPUT ACCEPT [23057:1705962]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [21647:2926456]
:POSTROUTING ACCEPT [21647:2926456]
COMMIT
# Completed on Mon Aug 15 23:04:03 2005
# Generated by iptables-save v1.3.3 on Mon Aug 15 23:04:03 2005
*filter
:INPUT ACCEPT [11368:866156]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [21603:2922235]
COMMIT
# Completed on Mon Aug 15 23:04:03 2005



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

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

[Michael Hallager]

AS FOLLOWS: (Opps. my mistake!)

root@202-150-101-225:/home/michael# iptables-save
# Generated by iptables-save v1.3.3 on Mon Aug 15 23:29:05 2005
*mangle
:PREROUTING ACCEPT [26426:1982742]
:INPUT ACCEPT [26426:1982742]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [24934:3548792]
:POSTROUTING ACCEPT [24934:3548792]
COMMIT
# Completed on Mon Aug 15 23:29:05 2005
# Generated by iptables-save v1.3.3 on Mon Aug 15 23:29:05 2005
*filter
:INPUT DROP [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [24885:3543903]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -d 202.150.101.225 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -d 202.150.101.225 -p tcp -m layer7 --l7proto smtp -m tcp --dport 25 
-j ACCEPT
-A INPUT -d 202.150.101.225 -p tcp -m layer7 --l7proto dns -m tcp --dport 53 
-j ACCEPT
-A INPUT -d 202.150.101.225 -p udp -m layer7 --l7proto dns -m udp --dport 53 
-j ACCEPT
-A INPUT -d 202.150.101.235 -p tcp -m layer7 --l7proto dns -m tcp --dport 53 
-j ACCEPT
-A INPUT -d 202.150.101.235 -p udp -m layer7 --l7proto dns -m udp --dport 53 
-j ACCEPT
-A INPUT -d 202.150.101.225 -p tcp -m layer7 --l7proto http -m tcp --dport 80 
-j ACCEPT
-A INPUT -d 202.150.101.225 -p tcp -m tcp --dport 110 -j ACCEPT
-A INPUT -d 202.150.101.226 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -d 202.150.101.227 -p tcp -m tcp --dport 443 -j ACCEPT
-A INPUT -s 129.223.123.249 -d 202.150.101.225 -p tcp -m tcp --dport 9050 -j 
ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Aug 15 23:29:05 2005
root@202-150-101-225:/home/michael#     



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

[Eric Leblond]

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

On Mon, 2005-08-15 at 23:32 +1200, Michael Hallager wrote:
> AS FOLLOWS: (Opps. my mistake!)
> 
> -A INPUT -i lo -j ACCEPT
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -d 202.150.101.225 -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -d 202.150.101.225 -p tcp -m layer7 --l7proto smtp -m tcp --dport 25 
> -j ACCEPT

l7filtering is completly useless here. In fact l7 is able to detect a
protocol after a few packets so your 
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
take precedence over l7 rules.
Furthermore (I may be mistaking) match is often done on reply thus
filtering on OUTPUT is necessary.
One other point is : why do you need to check the protocol running on
your own computer ?

BR,
-- 
Eric Leblond <eric@inl.fr>
INL

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

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

[/dev/rob0]

On Monday 2005-August-15 06:32, Michael Hallager wrote:
> AS FOLLOWS: (Opps. my mistake!)

Another mistake is that the script ("batch") in the OP would not have 
generated these rules. Having referred back to that I see you're using 
the netfilter drivers built-in rather than as modules. A *big* mistake. 
What is the benefit you expected to see from that choice?

Learn to walk before you try to run. "I have the bare number of needed 
modules compiled into the custom kernel," you said. But do you know 
what are really needed? I doubt it.

> root@202-150-101-225:/home/michael# iptables-save
> # Generated by iptables-save v1.3.3 on Mon Aug 15 23:29:05 2005
> *mangle

You (was it you?) compiled in mangle support; you're not using it.

> *filter
>
> :INPUT DROP [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [24885:3543903]
>
> -A INPUT -i lo -j ACCEPT
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -d 202.150.101.225 -p tcp -m tcp --dport 22 -j ACCEPT

The destination IP addresses were not in the script posted.

> -A INPUT -d 202.150.101.225 -p tcp -m layer7 --l7proto smtp -m tcp
> --dport 25 -j ACCEPT

layer7 was DEFINITELY not mentioned. Is this not only available as a 
patch? From an unpatched slackware-current install:
# iptables -vA INPUT -m layer7 -l7proto smtp
iptables v1.3.3: Couldn't load match 
`layer7':/usr/lib/iptables/libipt_layer7.so: cannot open shared object 
file: No such file or directory

Did you not configure this machine yourself? If you did, why did you 
choose layer7 filtering? And why would you not have considered that a 
relevant fact in posting your question? Either you deliberately put us 
through a silly guessing game, or you have no idea what you are doing 
with your kernel.

Why do we see so many posters who post before RTFM?

> -A INPUT -d 202.150.101.225 -p tcp -m layer7 --l7proto dns -m tcp
> --dport 53 -j ACCEPT

Do you even understand what layer7 filtering does? I don't use it 
myself, nor am I likely to do so in the future, but my high-level 
understanding is that it inspects the content of each packet against 
protocol definitions to see if it matches.

It's a fun idea, but it's ugly and slow in practice. No wonder your 
firewall is slowing things down.

In GNU/Linux, things will mostly work as designed. When you start 
patching and changing things, be sure you know what you are doing.

In my years of learning and doing I have certainly encountered my fair 
share of frustration. But as a rule I've found that by leaving things 
alone until I understand them, I am much more successful.

Dx: severe Clue deficiency
Rx: revert to a Slackware kernel/modules
Rx: RTFM: http://netfilter.org/documentation/
Rx: RTFM: http://slackbook.org/html/
Px: GOOD, if Rx followed; POOR otherwise
-- 
    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

[Jörg Harmuth]

Oohps, forgot to send to the list :(

Michael Hallager schrieb:
[SNIP]

> *filter
> :INPUT DROP [0:0]
> :FORWARD ACCEPT [0:0]
> :OUTPUT ACCEPT [24885:3543903]
> -A INPUT -i lo -j ACCEPT
> -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
> -A INPUT -d 202.150.101.225 -p tcp -m tcp --dport 22 -j ACCEPT
> -A INPUT -d 202.150.101.225 -p tcp -m layer7 --l7proto smtp -m tcp --dport 25 
> -j ACCEPT
> -A INPUT -d 202.150.101.225 -p tcp -m layer7 --l7proto dns -m tcp --dport 53 
> -j ACCEPT
> -A INPUT -d 202.150.101.225 -p udp -m layer7 --l7proto dns -m udp --dport 53 
> -j ACCEPT
> -A INPUT -d 202.150.101.235 -p tcp -m layer7 --l7proto dns -m tcp --dport 53 
> -j ACCEPT
> -A INPUT -d 202.150.101.235 -p udp -m layer7 --l7proto dns -m udp --dport 53 
> -j ACCEPT
> -A INPUT -d 202.150.101.225 -p tcp -m layer7 --l7proto http -m tcp --dport 80 
> -j ACCEPT
> -A INPUT -d 202.150.101.225 -p tcp -m tcp --dport 110 -j ACCEPT
> -A INPUT -d 202.150.101.226 -p tcp -m tcp --dport 443 -j ACCEPT
> -A INPUT -d 202.150.101.227 -p tcp -m tcp --dport 443 -j ACCEPT
> -A INPUT -s 129.223.123.249 -d 202.150.101.225 -p tcp -m tcp --dport 9050 -j 
> ACCEPT
> -A OUTPUT -o lo -j ACCEPT
> COMMIT
> # Completed on Mon Aug 15 23:29:05 2005
> root@202-150-101-225:/home/michael#     

Ok, I see. I think your problem is related to L7, 'cause you cannot have
a policy of DROP with L7. The following is likely to happen:

1.) You get e.g. an SMTP request == SYN bit set.
2.) As none of your rules match the packet hits the policy,
    which is DROP.
3.) L7 is never able to recognize the SMTP protocol.

So I don't think that the network speed is slowed down, I think there is
no SMTP, DNS and HTTP connection at all. You have no problem with POP3
and HTTPS, right ?

I would recommend the following:

1.) Move your L7 rules to mangle/PREROUTING *and* mangle/POSTROUTING.
    This is because you don't forward the packets. As Eric said,
    some protocols are recognized in OUTPUT and some in INPUT.
2.) Omit the port with L7. L7 is designed for detecting protocols,
    even on non standard ports (well, that's one point :)) You
    may omit -p too.
3.) Don't rely on L7 in terms of security (you read the HOWTO ?) !!
4.) Filter in filter table. If you really want to filter with L7,
    I think it's best, to mark the packets in PREROUTING and
    and then filter based on the marks in filter table. Only my 2C.

If you don't have the need of recognizing protocols (means: using L7 for
convenience), do standard filtering like port matches and so on using
connection tracking (so, compile nat into the kernel).

HTH and have a nice time,

Joerg