RE: New connection to windows boxes very slow, very fast afterinitial delay

RE: New connection to windows boxes very slow, very fast afterinitial delay

[Miguel Laborde]

Hi Ray, 
	thanks for the reply however I don't think this is a netbios issue. I realize I said \\dmzmachine but really in this case I'm using an IP address and I'm connecting to the c$ drive so there shouldn't be any Netbios name lookups (unless Windows does this either way) and neither a need to query for shares. Farthermore, this firewall is a replacement for another which was no where as restrictive; no tracking of internal connections to the dmz in a stateful manner. The part that farther makes me suspicious is why does the src machine start sending packets with the AP flags and never receive anything back from the dst machine until it starts a new SYN connection (aside from the ICMP request/reply just before hand)? If the explanation was one of latency I would expect to see this apply to internal machines too and not just when connecting to DMZ machines. In my mind there is no way that a 10second delay can be explained simply due to a few extra meters of network cable and having to pass through the firewall from one subnet to another, especially since there is no traffic delay between machines once the initially delay has passed.


-----Original Message-----
From: netfilter-admin@lists.netfilter.org
[mailto:netfilter-admin@lists.netfilter.org]On Behalf Of Ray Leach
Sent: Tuesday, March 16, 2004 1:08 AM
To: Netfilter Mailing List
Subject: Re: New connection to windows boxes very slow, very fast
afterinitial delay


On Mon, 2004-03-15 at 16:27, Miguel Laborde wrote:
> Hello all,
> 
> 	I have a question that I'm sure some of you will be able to answer since I vaguely remember something which might be related to
>  this. Awhile ago I read that MS had implemented a nonstandard 'feature' with respect to TCP/IP in which they appeared to skip the SYN 
> step and go straight to an ACK for re-establishing a connection to a previously (assumeably within a certain time constraint) connected 
> machine. Here is the article I was rememebering(just found it on Google), now this has to do with IE, but I'm sure this 'feature' 
> happens at the stack level and not application so it applies to any network related activity 
> - http://grotto11.com/blog/slash.html?+1039831658
> 
> 	I'm having a similiar situation when connecting from a windows machine to another windows machine in the DMZ with an 
> iptables firewall between. I've noticed, as well as others, that after not connecting to the machine for awhile (ie: after a weekend) 
> the initial connection results in about a 10-15 second delay however following connections are instantaneous. When I say connection 
> here I'm meaning connection to a share on the machine such as \\dmzmachine\share and the explore window popping up. 

This is the way that the SMB protocol works. It is UDP based, and
therefore 'connectionless' and entirely based on broadcasts. What is
most likely happening is that the local netbios name cache on your
source machine has been expunged of old entries (probably a preset time)
and your machine therefore has to re-lookup the ip/name pair for the
target machine and possibly re-authenticate, re-query all the shares,
etc.
> 
> 	I've capture the interation with snort and noticed something that seems to confirm what I state in the first paragraph.
> 
> 	After the weekend, haven't connected for days, this is the initial connection (all the Snort output). Note the packet flags are AP until there is some ICMP activity, presumably checking the host is up, and then starting with a SYN packet. When I try again we carry off right away with the an ACK/PUSH packet without any delay. My assumption is iptables has timed out the connection after seeing no activity for hours and as a result deleted it from memory. When the windows machine tries to reconnect without a SYN packet it never gets through since IPtables has no memory of this ever being an established connection.  Does my conclusion sound reasonable to others?
> 

<snip>

RE: New connection to windows boxes very slow, very fast afterinitial delay

[Chris Brenton]

On Tue, 2004-03-16 at 10:33, Miguel Laborde wrote:
> Hi Ray, 
> 	thanks for the reply however I don't think this is a netbios issue. I realize I said \\dmzmachine but really in this case I'm using an IP address and I'm connecting to the c$ drive so there shouldn't be any Netbios name lookups

I think you are confused. _NetBEUI_ is its own stand-alone protocol.
When older systems use IP, its actually NetBIOS/IP. Do a:
netstat -an

and you should see ports between 137-139 open. These are the NetBIOS
ports.

As for your question about Windows creating a new session based on an
ACK packet, this is false. Windows properly returns a RST to these
packets. SYN and SYN/PSH are the only two valid flag combinations I've
found on Windows for connection establishment. 

Now, it *could* be that you are banging your head against the state
table time out. This is 5 days by default, or less if one end signals a
Window size of zero (time-wait). If the session is sitting quieter for
longer than that, Netfilter could be killing the session. You could fix
this by writing a rule that passes ACK packets from the outside host,
but this would be a potential security hole. Best fix would be some kind
of a keep alive (file copy running on a scheduled process or something
similar).

HTH,
Chris