|
Hi list,
I was doing tests with iptables on redhat 7.3 ,
iptables version 1.2.5 and I observed that windows tcp client (telnet) doesn´t
answer in the same time that unix tcp client (telnet) is doing.
(This test is so simple to do)
For example: I have a telnet daemon listening on
port 23 of a Redhat 7.3 (192.168.0.1) and two more machines that will work as
client of this daemon on this example. One of them Windows 2000 (192.168.0.2)
and the another Solaris 2.6 (192.168.0.3). I have my lan connection OK, so the
clients can achieve the server using a telnet client normally.
To start the test I added a rule to block the
connections that came from the two clients I have.
iptables -A INPUT -p tcp --source 192.168.0.2
--dport 23 -j REJECT
iptables -A INPUT -p tcp --source 192.168.0.3
--dport 23 -j REJECT
On the client side I do a "telnet 192.168.0.1" and
what I got:
On the Solaris machine: a very fast response that
the connection was refused.
On the Windows 2000 machine: after for
about 20 seconds I got the message that the connect failed (I thing this is
the same as connection refused).
Doing another test on the Windows2000 machine. That
time I used telnet to connect on a port that doesn´t exists on my RedHat server.
c:> telnet 192.168.0.1 30
Connecting To 192.168.0.1...Could not open a
connection to host on port 30: Connect failed
This is the same error I got when I use the port
that is blocked with "reject" by iptables on server side, BUT the difference is
that I get the error after 1 or 2 seconds after executing the
command.
Conclusion: I think this
was because the Windows implementation of TCP detects something different on
this connection, maybe it detects in some way that there is a filter on the
server side and this is why the time for the error message take so long to
appear.
Am I right? Is there a workaround for this problem?
I need to make windows think that the server is really "down" and that is why
i´m writting to you people.
I will appreciate any help.
Thanks in advance,
Fabiano |
