differences between win and unix tcp clients.

differences between win and unix tcp clients.

[Fabiano Reis]

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

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

[-- Attachment #2: Type: text/html, Size: 4031 bytes --]

differences between win and unix tcp clients.

[Fabiano Reis]

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

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

[-- Attachment #2: Type: text/html, Size: 4031 bytes --]

Re: differences between win and unix tcp clients.

[Chris Brenton]

On Tue, 2004-03-16 at 07:12, Fabiano Reis wrote:
>
> 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 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).

If you don't specify a reject option, the default is an ICMP port
unreachable. This is an odd thing to return for a closed TCP port, as
normally it would be an ACK/RST.

So I'm guessing that Solaris handles this like an ACK/RST while Windows
handles this like any generic type 3 error. Doing a:

-J REJECT --reject-with tcp-reset

would produce more consistent results, however you are running such an
old version of iptables I *think* that version was still returning bad
sequence numbers on the RST's. It might work for you, it might not. You
should really upgrade.

HTH,
C

Re: differences between win and unix tcp clients.

[Fabiano Reis]

It worked. Thanks.


----- Original Message ----- 
From: "Chris Brenton" <cbrenton@chrisbrenton.org>
To: "Fabiano Reis" <silos.reis@ig.com.br>
Cc: <netfilter@lists.netfilter.org>
Sent: Tuesday, March 16, 2004 9:41 AM
Subject: Re: differences between win and unix tcp clients.


> On Tue, 2004-03-16 at 07:12, Fabiano Reis wrote:
> >
> > 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 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).
> 
> If you don't specify a reject option, the default is an ICMP port
> unreachable. This is an odd thing to return for a closed TCP port, as
> normally it would be an ACK/RST.
> 
> So I'm guessing that Solaris handles this like an ACK/RST while Windows
> handles this like any generic type 3 error. Doing a:
> 
> -J REJECT --reject-with tcp-reset
> 
> would produce more consistent results, however you are running such an
> old version of iptables I *think* that version was still returning bad
> sequence numbers on the RST's. It might work for you, it might not. You
> should really upgrade.
> 
> HTH,
> C
> 
> 
> 
> 

Re: differences between win and unix tcp clients.

[Joshua Goodall]

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

(netfilter-devel removed from CC list)

On Tue, Mar 16, 2004 at 09:12:01AM -0300, Fabiano Reis wrote:
> 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.

Basically yes.  I wouldn't say that Windows "detects something
different".   I would say that the Windows client isn't properly
interpretating the ICMP Port Unreachable message.

> 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.

try extending your REJECT option:

-j REJECT --reject-with tcp-reset

which should give you the desired result, in exchange for being
a crude pseudo-rejection.

Joshua.

-- 
Joshua Goodall <joshua@myinternet.com.au>
Solutions Architect / Principal Security Architect
myinternet Limited.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: differences between win and unix tcp clients.

[Nuutti Kotivuori]

Joshua Goodall wrote:
> On Tue, Mar 16, 2004 at 09:12:01AM -0300, Fabiano Reis wrote:
>> 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.
>
> Basically yes.  I wouldn't say that Windows "detects something
> different".   I would say that the Windows client isn't properly
> interpretating the ICMP Port Unreachable message.

Incorrect. Receiving an ICMP port unreachable message should not cause
a break in the connection attempt - it should be retried until SYN
timeout, at which point it can be informed that there was an ICMP port
unreachamble message received during the period.

So Windows is acting properly.

>> 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.
>
> try extending your REJECT option:
>
> -j REJECT --reject-with tcp-reset
>
> which should give you the desired result, in exchange for being
> a crude pseudo-rejection.

If you wish to get immediate reject responses, TCP reset is the only
way. It has nothing more or less crude than sending an ICMP.

-- Naked

Re: differences between win and unix tcp clients.

[netfilter-devel]

Fabiano Reis writes:

>
> 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.

You are right, tcp/ip stacks are different. In this the difference shows
case the filtered port will send back a host-unreachable while the closed
port will send back a TCP-reset. It is best to always send back a TCP reset
when rejecting tcp, all stacks react good to this (they better do, it's in
the RFC). So add a --with-tcp-reset to jour reject and you should be OK.

HTH,
Martijn Lievaart

Re: differences between win and unix tcp clients.

[netfilter-devel]

Fabiano Reis writes:

>
> 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.

You are right, tcp/ip stacks are different. In this the difference shows
case the filtered port will send back a host-unreachable while the closed
port will send back a TCP-reset. It is best to always send back a TCP reset
when rejecting tcp, all stacks react good to this (they better do, it's in
the RFC). So add a --with-tcp-reset to jour reject and you should be OK.

HTH,
Martijn Lievaart

Re: differences between win and unix tcp clients.

[Nuutti Kotivuori]

netfilter-devel@rtij.nl wrote:
> Fabiano Reis writes:
>> 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.
>
> You are right, tcp/ip stacks are different. In this the difference
> shows case the filtered port will send back a host-unreachable while
> the closed port will send back a TCP-reset. It is best to always
> send back a TCP reset when rejecting tcp, all stacks react good to
> this (they better do, it's in the RFC). So add a --with-tcp-reset to
> jour reject and you should be OK.

Send TCP reset if you wish to get immediate response.

TCP/IP stacks which interrupt connection attempts on ICMP
host-unreachable are broken implementations. ICMP messages are
advisory and insecure. The message shown, host unreachable, is merely
advisory - the actual thing the machine is telling you is that the
connection timed out and that in _addition_ a host unreachable message
was received during the timeout which might very well be related, but
which is not definitive.

-- Naked

Re: differences between win and unix tcp clients.

[Henrik Nordstrom]

On Tue, 16 Mar 2004, Fabiano Reis wrote:

> 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

For best operation you should reject TCP packets with a "TCP RESET". See
the documentation for the REJECT target.

By default REJECT rejects the packet by returing an "ICMP Administratively 
Probited" message, and different TCP implementation behave differently in 
receiving this message.

The semantic difference between using TCP Reset or ICMP administratively 
probited is that TCP Reset tells the client that the TCP port is closed 
while the ICMP message tells the client that he is not allowed to talk to 
this port.

Regards
Henrik

Re: differences between win and unix tcp clients.

[Henrik Nordstrom]

On Tue, 16 Mar 2004, Fabiano Reis wrote:

> 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

For best operation you should reject TCP packets with a "TCP RESET". See
the documentation for the REJECT target.

By default REJECT rejects the packet by returing an "ICMP Administratively 
Probited" message, and different TCP implementation behave differently in 
receiving this message.

The semantic difference between using TCP Reset or ICMP administratively 
probited is that TCP Reset tells the client that the TCP port is closed 
while the ICMP message tells the client that he is not allowed to talk to 
this port.

Regards
Henrik