From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Fabiano Reis" Subject: differences between win and unix tcp clients. Date: Tue, 16 Mar 2004 09:12:01 -0300 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <024b01c40b4f$e3341620$3f32a8c0@ds.ig.com.br> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0248_01C40B36.BDCE7420" Return-path: Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: To: netfilter@lists.netfilter.org Cc: netfilter-devel@lists.netfilter.org This is a multi-part message in MIME format. ------=_NextPart_000_0248_01C40B36.BDCE7420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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=B4t 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=B4t exists on my RedHat server.=20 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=B4m = writting to you people. I will appreciate any help. Thanks in advance, Fabiano ------=_NextPart_000_0248_01C40B36.BDCE7420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi list,
 
I was doing tests with iptables on = redhat 7.3 ,=20 iptables version 1.2.5 and I observed that windows tcp client (telnet) = doesn=B4t=20 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=20 port 23 of a Redhat 7.3 (192.168.0.1) and two more machines that will = work as=20 client of this daemon on this example. One of them Windows 2000 = (192.168.0.2)=20 and the another Solaris 2.6 (192.168.0.3). I have my lan connection OK, = so the=20 clients can achieve the server using a telnet client = normally.
 
To start the test I added a rule to = block the=20 connections that came from the two clients I have.
 
iptables -A INPUT -p tcp --source = 192.168.0.2=20 --dport 23 -j REJECT
iptables -A INPUT -p tcp --source = 192.168.0.3=20 --dport 23 -j REJECT
 
On the client side I do a "telnet = 192.168.0.1" and=20 what I got:
 
On the Solaris machine: a very fast = response that=20 the connection was refused.
 
On the Windows 2000 machine: = after for=20 about 20 seconds I got the message that the connect failed (I thing = this is=20 the same as connection refused).
 
Doing another test on the Windows2000 = machine. That=20 time I used telnet to connect on a port that doesn=B4t exists on my = RedHat server.=20
 
c:> telnet 192.168.0.1 = 30
Connecting To 192.168.0.1...Could not = open a=20 connection to host on port 30: Connect failed
 
This is the same error I got when I use = the port=20 that is blocked with "reject" by iptables on server side, BUT the = difference is=20 that I get the error after 1 or 2 seconds after executing the=20 command.
 
Conclusion: I think this=20 was because the Windows implementation of TCP detects something = different on=20 this connection, maybe it detects in some way that there is a filter on = the=20 server side and this is why the time for the error message take so = long to=20 appear.
 
Am I right? Is there a workaround for = this problem?=20 I need to make windows think that the server is really "down" and that = is why=20 i=B4m writting to you people.
 
I will appreciate any = help.
 
Thanks in advance,
 
Fabiano
------=_NextPart_000_0248_01C40B36.BDCE7420-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Brenton Subject: Re: differences between win and unix tcp clients. Date: Tue, 16 Mar 2004 07:41:17 -0500 Sender: netfilter-admin@lists.netfilter.org Message-ID: <1079440877.2021.71.camel@grendel> References: <024b01c40b4f$e3341620$3f32a8c0@ds.ig.com.br> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <024b01c40b4f$e3341620$3f32a8c0@ds.ig.com.br> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: Fabiano Reis Cc: netfilter@lists.netfilter.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Fabiano Reis" Subject: Re: differences between win and unix tcp clients. Date: Tue, 16 Mar 2004 10:30:08 -0300 Sender: netfilter-admin@lists.netfilter.org Message-ID: <037801c40b5a$ccdbb710$3f32a8c0@ds.ig.com.br> References: <024b01c40b4f$e3341620$3f32a8c0@ds.ig.com.br> <1079440877.2021.71.camel@grendel> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: Chris Brenton Cc: netfilter@lists.netfilter.org It worked. Thanks. ----- Original Message ----- From: "Chris Brenton" To: "Fabiano Reis" Cc: 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 > > > > From mboxrd@z Thu Jan 1 00:00:00 1970 From: netfilter-devel@rtij.nl Subject: Re: differences between win and unix tcp clients. Date: Tue, 16 Mar 2004 17:20:18 +0100 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: References: <024b01c40b4f$e3341620$3f32a8c0@ds.ig.com.br> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <024b01c40b4f$e3341620$3f32a8c0@ds.ig.com.br> Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; format="flowed"; charset="iso-8859-1" To: Fabiano Reis Cc: netfilter@lists.netfilter.org, netfilter-devel@lists.netfilter.org Fabiano Reis writes: > > Conclusion: I think this was because the Windows implementation of TCP= detects something different on this connection, maybe it detects in som= e 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 win= dows think that the server is really "down" and that is why i=C2=B4m wri= tting 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 close= d port will send back a TCP-reset. It is best to always send back a TCP re= set 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nuutti Kotivuori Subject: Re: differences between win and unix tcp clients. Date: Wed, 17 Mar 2004 05:31:55 +0200 Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: <87wu5kp2s4.fsf@aka.i.naked.iki.fi> References: <024b01c40b4f$e3341620$3f32a8c0@ds.ig.com.br> Mime-Version: 1.0 Content-Transfer-Encoding: quoted-printable Return-path: Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="iso-8859-1" To: netfilter-devel@lists.netfilter.org Cc: netfilter@lists.netfilter.org 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=C2=B4m 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Henrik Nordstrom Subject: Re: differences between win and unix tcp clients. Date: Wed, 17 Mar 2004 08:19:16 +0100 (CET) Sender: netfilter-devel-admin@lists.netfilter.org Message-ID: References: <024b01c40b4f$e3341620$3f32a8c0@ds.ig.com.br> Mime-Version: 1.0 Return-path: In-Reply-To: <024b01c40b4f$e3341620$3f32a8c0@ds.ig.com.br> Errors-To: netfilter-devel-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: TEXT/PLAIN; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Fabiano Reis Cc: netfilter@lists.netfilter.org, netfilter-devel@lists.netfilter.org 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Joshua Goodall Subject: Re: differences between win and unix tcp clients. Date: Wed, 17 Mar 2004 02:07:46 +1100 Sender: netfilter-admin@lists.netfilter.org Message-ID: <20040316150746.GA8506@myinternet.com.au> References: <024b01c40b4f$e3341620$3f32a8c0@ds.ig.com.br> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="J/dobhs11T7y2rNN" Return-path: Content-Disposition: inline In-Reply-To: <024b01c40b4f$e3341620$3f32a8c0@ds.ig.com.br> Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: To: Fabiano Reis Cc: netfilter@lists.netfilter.org --J/dobhs11T7y2rNN Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable (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 de= tects 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 window= s think that the server is really "down" and that is why i?m writting to yo= u 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. --=20 Joshua Goodall Solutions Architect / Principal Security Architect myinternet Limited. --J/dobhs11T7y2rNN Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAVxhCo8kg3R/NoUQRAjj8AKDLZK9VisDc/jiEAyKJTPu9iOzxNACcCqil XJKg+LpMd2Crj2hsXAo6GrI= =jxRr -----END PGP SIGNATURE----- --J/dobhs11T7y2rNN-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nuutti Kotivuori Subject: Re: differences between win and unix tcp clients. Date: Wed, 17 Mar 2004 23:13:39 +0200 Sender: netfilter-admin@lists.netfilter.org Message-ID: <871xnrnpmk.fsf@aka.i.naked.iki.fi> References: <024b01c40b4f$e3341620$3f32a8c0@ds.ig.com.br> <20040316150746.GA8506@myinternet.com.au> Mime-Version: 1.0 Return-path: Errors-To: netfilter-admin@lists.netfilter.org List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: netfilter@lists.netfilter.org 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