IPCHAINS REJECT rule logs 2 packets with 3-sec delay for connect

Hi. I'm mighty puzzled over the behaviour I'm experiencing with ipchains
and would appreciate help or advice.

I'm running linux 2.6.1 with ipchains 1.3.10 and the ipchains
compatibility module that came with linux 2.6.1. I appreciate that
ipchains has been superceded by iptables (I think!?) and I promise
that one day real soon now I'll upgrade my packet filtering, but
ipchains up to now has been doing everything I wanted.

I want to block web access to annoying 'advertisement' sites, and
to do this I set them up with a mock loopback address in /etc/hosts -
like 127.0.66.166 - so browser access to those sites will bounce.
If there's a better way to do this, by the way, please let me know;
I suppose there would be by now, with today's browsers (I'm using
Firefox 1.5). But the problem I'm experiencing with ipchains is still
intriguing.

The problem is - I run this command to insert my very first rule in
the OUTPUT chain:

ipchains -A output -p tcp -d 127.0.66.166 443 -j REJECT -l

so as to reject any attempts by my browser to connect to
127.0.66.166 on port 443 (which is bound to a listening process
on INADDR_ANY). I find that a connection attempt to this address
on a port which isn't being listened to - say, port 456 - returns
immediately, as you would expect:

time telnet 127.0.66.166 456

gives

Trying 127.0.66.166...
telnet: connect to address 127.0.66.166: Connection refused

real 0m0.045s
user 0m0.001s
sys 0m0.006s

but with a connection to port 443 the attempt HANGS for 3 seconds:

Trying 127.0.66.166...
telnet: connect to address 127.0.66.166: Connection refused

real 0m3.040s
user 0m0.001s
sys 0m0.002s

with these TWO lines logged by ipchains:

Feb 19 08:16:18 host kernel: Packet log: output REJECT lo PROTO=6 127.0.66.166:33353
127.0.66.166:443 L=60 S=0x10 I=14012 F=0x4000 T=64 SYN (#1)
Feb 19 08:16:21 host kernel: Packet log: output REJECT lo PROTO=6 127.0.66.166:33353
127.0.66.166:443 L=60 S=0x10 I=14013 F=0x4000 T=64 SYN (#1)

exactly three seconds apart.

When I strace the system call with "strace -T" it's apparent that the
delay is all in the single connect() to the port:

connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("127.0.66.166")}, 16) = -1
ECONNREFUSED (Connection refused) <2.999778>

- i.e. the connect() call is taking 2.999778 seconds to return.
There doesn't appear to be delays built into the telnet program, it's
not trying to do two separate connections, etcetera; the single
connect() itself is for some reason registering TWO hits on the ipchains
REJECT rule with three seconds between them.

That's as far as I can go; I'm bewildered. Can someone tell me
why this is happening?

Many thanks,


Brad

 

There are IP blacklisting modules for Firefox; names escape me for now,
but have a look in the module repository.

You might wish to try whether
ipchains -A output -p tcp -d 127.0.66.166 443 -j REJECT --reject-with tcp-reset -l
makes any difference.

Subtle nuances in the TCP protocol.. the 'tcp-reset' should be the correct
way of telling the client not to try again.

 

-A INPUT -s 123.123.123.123/255.255.255.255 -j DROP

works for me

sin_addr=inet_addr("127.0.66.166")}, 16) = -1