Hello all, I've been working on figuring out the problem listed above for 4 months and it seems to defy all possible explaination. The network I run is a set of computers using NAT(One outsite IP to many Inside IPs) that connect to our Win2K8 File Server/DC in another building on another VLAN in a different subnet across the campus network. The problem is that I will sporadically get "The Specified Network Name is No Longer Available" and the users desktop icons, start menu, my docs folder will disappear (we use folder and desktop redirection) and not come back for a period of anywhere from 2 to 5 minutes in the past now they come back nearly instantly. My users have taken to calling it the problem of the disappearing icons because that is its biggest symptom. In my fighting with this problem I have gotten WINS appropriately set up on the DC and all the clients point to it as their primary WINS Server and their Primary DNS server since DNS is installed on the same server. The server itself is a Dell PowerEdge 2950 III with a Broadcom 5708C NetXtreme II 1-Gigabit NIC. I've also set the NAT box to be as wide open as possible to eliminate that vector for the problem. We have the network filtered from the outside by a Cisco Virtual Firewall on the Core Routers but the Server and the Workstations have total full open access to each other. I'm moving away from using the NAT setup soon but I'm just curious about the answer to why this happens. Here is a a packet capture from Wireshark that shows what I found to be the repeating pattern when this error appears in its random way. It is characterized by a whole seemingly normal SMB conversation over port 445 but then it ends abruptly with an RST, ACK packet from the Server and kills the conversation right at the end until it decides to stop doing that and work again. Below is the 15 Packet run that is a sample of the problem. I have a large Wireshark pcap file with this pattern repeated in it. o. Time Source Destination Protocol Info 114 13.918037 192.168.0.72 142.103.194.33 TCP techra-server > microsoft-ds [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Frame 114 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb), Dst: Cisco_4b:67:6d (00:23:04:4b:67:6d) Internet Protocol, Src: 192.168.0.72 (192.168.0.72), Dst: 142.103.194.33 (142.103.194.33) Transmission Control Protocol, Src Port: techra-server (1862), Dst Port: microsoft-ds (445), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 115 13.918096 192.168.0.72 142.103.194.33 TCP msnp > netbios-ssn [SYN] Seq=0 Win=65535 Len=0 MSS=1460 Frame 115 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb), Dst: Cisco_4b:67:6d (00:23:04:4b:67:6d) Internet Protocol, Src: 192.168.0.72 (192.168.0.72), Dst: 142.103.194.33 (142.103.194.33) Transmission Control Protocol, Src Port: msnp (1863), Dst Port: netbios-ssn (139), Seq: 0, Len: 0 No. Time Source Destination Protocol Info 116 13.919313 142.103.194.33 192.168.0.72 TCP microsoft-ds > techra-server [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1380 Frame 116 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: Cisco_4b:67:6d (00:23:04:4b:67:6d), Dst: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb) Internet Protocol, Src: 142.103.194.33 (142.103.194.33), Dst: 192.168.0.72 (192.168.0.72) Transmission Control Protocol, Src Port: microsoft-ds (445), Dst Port: techra-server (1862), Seq: 0, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 117 13.919336 192.168.0.72 142.103.194.33 TCP techra-server > microsoft-ds [ACK] Seq=1 Ack=1 Win=65535 Len=0 Frame 117 (54 bytes on wire, 54 bytes captured) Ethernet II, Src: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb), Dst: Cisco_4b:67:6d (00:23:04:4b:67:6d) Internet Protocol, Src: 192.168.0.72 (192.168.0.72), Dst: 142.103.194.33 (142.103.194.33) Transmission Control Protocol, Src Port: techra-server (1862), Dst Port: microsoft-ds (445), Seq: 1, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 118 13.919339 142.103.194.33 192.168.0.72 TCP netbios-ssn > msnp [SYN, ACK] Seq=0 Ack=1 Win=8192 Len=0 MSS=1380 Frame 118 (62 bytes on wire, 62 bytes captured) Ethernet II, Src: Cisco_4b:67:6d (00:23:04:4b:67:6d), Dst: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb) Internet Protocol, Src: 142.103.194.33 (142.103.194.33), Dst: 192.168.0.72 (192.168.0.72) Transmission Control Protocol, Src Port: netbios-ssn (139), Dst Port: msnp (1863), Seq: 0, Ack: 1, Len: 0 No. Time Source Destination Protocol Info 119 13.919352 192.168.0.72 142.103.194.33 SMB Negotiate Protocol Request Frame 119 (191 bytes on wire, 191 bytes captured) Ethernet II, Src: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb), Dst: Cisco_4b:67:6d (00:23:04:4b:67:6d) Internet Protocol, Src: 192.168.0.72 (192.168.0.72), Dst: 142.103.194.33 (142.103.194.33) Transmission Control Protocol, Src Port: techra-server (1862), Dst Port: microsoft-ds (445), Seq: 1, Ack: 1, Len: 137 NetBIOS Session Service SMB (Server Message Block Protocol) No. Time Source Destination Protocol Info 120 13.920408 142.103.194.33 192.168.0.72 SMB Negotiate Protocol Response Frame 120 (251 bytes on wire, 251 bytes captured) Ethernet II, Src: Cisco_4b:67:6d (00:23:04:4b:67:6d), Dst: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb) Internet Protocol, Src: 142.103.194.33 (142.103.194.33), Dst: 192.168.0.72 (192.168.0.72) Transmission Control Protocol, Src Port: microsoft-ds (445), Dst Port: techra-server (1862), Seq: 1, Ack: 138, Len: 197 NetBIOS Session Service SMB (Server Message Block Protocol) No. Time Source Destination Protocol Info 121 13.920705 192.168.0.72 142.103.194.33 TCP [TCP segment of a reassembled PDU] Frame 121 (1434 bytes on wire, 1434 bytes captured) Ethernet II, Src: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb), Dst: Cisco_4b:67:6d (00:23:04:4b:67:6d) Internet Protocol, Src: 192.168.0.72 (192.168.0.72), Dst: 142.103.194.33 (142.103.194.33) Transmission Control Protocol, Src Port: techra-server (1862), Dst Port: microsoft-ds (445), Seq: 138, Ack: 198, Len: 1380 No. Time Source Destination Protocol Info 122 13.920711 192.168.0.72 142.103.194.33 TCP [TCP segment of a reassembled PDU] Frame 122 (1434 bytes on wire, 1434 bytes captured) Ethernet II, Src: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb), Dst: Cisco_4b:67:6d (00:23:04:4b:67:6d) Internet Protocol, Src: 192.168.0.72 (192.168.0.72), Dst: 142.103.194.33 (142.103.194.33) Transmission Control Protocol, Src Port: techra-server (1862), Dst Port: microsoft-ds (445), Seq: 1518, Ack: 198, Len: 1380 No. Time Source Destination Protocol Info 123 13.920716 192.168.0.72 142.103.194.33 SMB Session Setup AndX Request Frame 123 (216 bytes on wire, 216 bytes captured) Ethernet II, Src: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb), Dst: Cisco_4b:67:6d (00:23:04:4b:67:6d) Internet Protocol, Src: 192.168.0.72 (192.168.0.72), Dst: 142.103.194.33 (142.103.194.33) Transmission Control Protocol, Src Port: techra-server (1862), Dst Port: microsoft-ds (445), Seq: 2898, Ack: 198, Len: 162 [Reassembled TCP Segments (2922 bytes): #121(1380), #122(1380), #123(162)] NetBIOS Session Service SMB (Server Message Block Protocol) No. Time Source Destination Protocol Info 124 13.922345 142.103.194.33 192.168.0.72 TCP microsoft-ds > techra-server [ACK] Seq=198 Ack=3060 Win=64860 Len=0 Frame 124 (60 bytes on wire, 60 bytes captured) Ethernet II, Src: Cisco_4b:67:6d (00:23:04:4b:67:6d), Dst: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb) Internet Protocol, Src: 142.103.194.33 (142.103.194.33), Dst: 192.168.0.72 (192.168.0.72) Transmission Control Protocol, Src Port: microsoft-ds (445), Dst Port: techra-server (1862), Seq: 198, Ack: 3060, Len: 0 No. Time Source Destination Protocol Info 125 13.923276 142.103.194.33 192.168.0.72 SMB Session Setup AndX Response Frame 125 (444 bytes on wire, 444 bytes captured) Ethernet II, Src: Cisco_4b:67:6d (00:23:04:4b:67:6d), Dst: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb) Internet Protocol, Src: 142.103.194.33 (142.103.194.33), Dst: 192.168.0.72 (192.168.0.72) Transmission Control Protocol, Src Port: microsoft-ds (445), Dst Port: techra-server (1862), Seq: 198, Ack: 3060, Len: 390 NetBIOS Session Service SMB (Server Message Block Protocol) No. Time Source Destination Protocol Info 126 13.923400 192.168.0.72 142.103.194.33 SMB Tree Connect AndX Request, Path: \\CHANDC\USERS Frame 126 (138 bytes on wire, 138 bytes captured) Ethernet II, Src: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb), Dst: Cisco_4b:67:6d (00:23:04:4b:67:6d) Internet Protocol, Src: 192.168.0.72 (192.168.0.72), Dst: 142.103.194.33 (142.103.194.33) Transmission Control Protocol, Src Port: techra-server (1862), Dst Port: microsoft-ds (445), Seq: 3060, Ack: 588, Len: 84 NetBIOS Session Service SMB (Server Message Block Protocol) No. Time Source Destination Protocol Info 127 13.924382 142.103.194.33 192.168.0.72 SMB Tree Connect AndX Response Frame 127 (120 bytes on wire, 120 bytes captured) Ethernet II, Src: Cisco_4b:67:6d (00:23:04:4b:67:6d), Dst: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb) Internet Protocol, Src: 142.103.194.33 (142.103.194.33), Dst: 192.168.0.72 (192.168.0.72) Transmission Control Protocol, Src Port: microsoft-ds (445), Dst Port: techra-server (1862), Seq: 588, Ack: 3144, Len: 66 NetBIOS Session Service SMB (Server Message Block Protocol) No. Time Source Destination Protocol Info 128 13.924444 192.168.0.72 142.103.194.33 SMB Trans2 Request, FIND_FIRST2, Pattern: \bengkhoo\Desktop\* Frame 128 (178 bytes on wire, 178 bytes captured) Ethernet II, Src: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb), Dst: Cisco_4b:67:6d (00:23:04:4b:67:6d) Internet Protocol, Src: 192.168.0.72 (192.168.0.72), Dst: 142.103.194.33 (142.103.194.33) Transmission Control Protocol, Src Port: techra-server (1862), Dst Port: microsoft-ds (445), Seq: 3144, Ack: 654, Len: 124 NetBIOS Session Service SMB (Server Message Block Protocol) No. Time Source Destination Protocol Info 129 13.926579 142.103.194.33 192.168.0.72 TCP microsoft-ds > techra-server [RST, ACK] Seq=654 Ack=3268 Win=0 Len=0 Frame 129 (60 bytes on wire, 60 bytes captured) Ethernet II, Src: Cisco_4b:67:6d (00:23:04:4b:67:6d), Dst: IntelCor_2a:81:fb (00:1c:c0:2a:81:fb) Internet Protocol, Src: 142.103.194.33 (142.103.194.33), Dst: 192.168.0.72 (192.168.0.72) Transmission Control Protocol, Src Port: microsoft-ds (445), Dst Port: techra-server (1862), Seq: 654, Ack: 3268, Len: 0 If I've also stumbled about on the internet and found MS KB 301673 that talks about how you can only have one connection at at time to a Server from a NAT Device but it claims to have been fixed in Win2k3 so that shouldn't be affecting a Win2K8 server with XP, 2k, and Vista clients. If anyone has any insight about this I would be glad to know it because I've beaten my head against the wall so many times on this problem it isn't even funny. Thanks in advance, Gary

Gary, it looks from the last packet as though the RST, ACK is coming from your remote server. This would imply to me that the other end is asking to terminate the connection. Please let me know if I'm not reading this right. Anyway, the reason I mention it is because we are seeing almost EXACTLY this behavior on our Win2K8 SFTP / FTPS server, but only during large file writes. We are connecting to a NetApp NAS via SMB for file storage for incoming SFTP or FTPS transfers, and if you transfer a sufficiently large file, it WILL fail at some point during the transfer. Wireshark captures show the same thing...a RST, ACK packet coming from the remote server, which causes the Win2K8 server to drop the SMB connection and re-negotiate. This effectively kills our large file transfers with a write error, even though the storage comes back online almost immediately. I, too, am pulling my hair out over this, and have yet to find a fix. Funny thing is, in my case, it ONLY exhibits the behavior on Win2K8, running in a VM, talking to the NetApp. I do not see it with any physical boxes, I do not see it with any Win2K3 VM's, and I do not see it with any machines talking to storage other than our NetApp. This is incredibly maddening.

Dave, I'm right there with you on the fact that it is maddening. You are right that the last packet does come from the Remote Server and whacks the client right on the head just as you mention. I have also seen the problem with large file transfers between client and server but only on XP and Win2K clients so far as I can tell not with a Vista client yet (I'm the only one running it in the office). i've done Wireshark captures on the server side as well and don't see much more than the RST, ACK packet going back out to the client. From the server perspective it is just sending it back to the NAT box that does all the translations. I know the OS's in VM's work on pretty much the same concept. While for me it does happen with phyiscal boxes I think that is only because they are all behind the NAT box (Cisco ASA 5510) and the Win2K8 server is off in another place. So far I haven't been able to find much exactly except that sometimes it seems to happen with Samba on Linux too but only in certain situations. I stumbled up on that in my many google searches. So I'm just curious if an answer will ever appear.

In searching through another Blog that I found linked off the NTDebugging blog (which is a Technet Blog) I discovered a great Windows Internals / Debugging site that posted about EXACTLY this issue. Turns out SMB (and the comments to the post suggest FTP might have the same problem) is profoundly incompatible with NAT and VPN's that do NAT. It seems that it has to do with the vcNumber of an SMB Setup Session and X request that makes the Server think the client has died and wants to start from scratch and also only seems to happen with newer clients that use Enhanaced Security on their SMB traffic. Here is the Fantastic Article from the Nynaeve Blog that I was just mentioning. It seems to explain everything and very clearly too. http://www.nynaeve.net/?p=93 Now if MS would just be nice make SMB over TCP behave properly in a Many to One (Overloaded NAT) situtation. I'm leaving the setup soon so it won't be a problem for me but it will still for others. Gary

Gary i would agree with you on the request to close coming from the client side rather than the server. I am running server 2003 with xp clients all on a simple lan. A few strange things i've noticed: 1: The disconnects happen at random could be a 50mb or a 2gb transfer it may work or may not apart from home directories mapped via AD profile settings which i haven't seen fail yet. 2: Transfers from/to various Linux live cd/installed os's seem to run fine, which suggeststhe SMB suites used in linux have some kind of workaround for the issue or theres a massive bug in all microsoft SMB client software...... hope this information is of help to someone EDIT: thanks Gary for the link http://www.nynaeve.net/?p=93 very informative.