When saving a file to a Windows Server 2003 host share from a VM running a Windows OS, a message from `Srv’ 2025 `The server has detected an attempted Denial-Of-Service attack from client \\*name*, and has disconnected the connection’ is logged, where *name* is that of said VM. The VM at the same time logs a redirector error and usually reports a cache write-back failure in an application pop-up.
[Note: From dejanews search, I consider the same problem reported with Microsoft Virtual Server 2005. I have no way to test whether the present resolution applies or not to that case, but it must be harmless enough to try it].
The problem occured to me only when saving files, and when the files are sufficiently large, in the tens of kilobytes vicinity. My hypothesis was that vmware bridge filter dumps virtual cable segment traffic into the physical interface network stack at an enormous rate for a 100 Mbps connection, and the OS sees this traffic as coming from the physical card driver.  I decided to reconfigure the host network to “disclose” the virtual cable segment traffic to the OS using Windows MAC bridging instead of vmware “behind the scenes” bridging.  I can neither confirm nor deny the correctness of this hypothesis, but in practice it resolved the issue.
I am assuming that you are using bridged configuration and one virtual network interface in each VM.
The procedure I performed was:
Shutdown all VMs that you are going to reconfigure.
Run vmware virtual network utility,  create an adapter (I will be using VMnet1 exempli gratia, but any other one except VMnet0 will work), and disconnect it from DHCP by removing it from the list on the DHCP page.  Unbinding DHCP from this adapter is important to avoid network problems.
According to the procedure at http://www.vmware.com/info?id=68, enable VMnet1 participation in a bridge:
Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class and look for the key {4D36E972-E325-11CE-BFC1-08002bE10318}. Make sure it is the right key by selecting it and verifying that (Default) has the value `Network adapters’.
Under {4D36E972-E325-11CE-BFC1-08002bE10318}, there are subkeys 0000, 0001, 0002 and so forth. Select each subkey until you find the one that corresponds to the VMnet adapter in question. The correct key has the DriverDesc with value `VMware Virtual Ethernet Adapter …’.
Add a DWORD value called AllowBindingToMACBridge, and set it to 1.
Bridge the physical and the new virtual connection, and assign the bridge correct network properties.
In the VMs, set network adapter configuration to `Custom’, then choose `VMnet1′ for the network.
This configuration puts all VMs on a single virtual cable segment, bridged explicitly, from the host OS point of view, to the physical interface driver.  Although the VMnet1 connection speed is still reported as 100 Mbps, and bursts of traffic clearly exceed that value by at least an orders of magnitude, the spurious DOS detection does not occur any more, at least on the same test files that I used (up to 100 MB).
[Modified by Mitch Tulloch] – 12 Nov 2004

When saving a file to a Windows Server 2003 host share from a VM running a Windows OS, a message from `Srv’ 2025 `The server has detected an attempted Denial-Of-Service attack from client \\*name*, and has disconnected the connection’ is logged, where *name* is that of said VM. The VM at the same time logs a redirector error and usually reports a cache write-back failure in an application pop-up.[Note: From dejanews search, I consider the same problem reported with Microsoft Virtual Server 2005. I have no way to test whether the present resolution applies or not to that case, but it must be harmless enough to try it].
The problem occured to me only when saving files, and when the files are sufficiently large, in the tens of kilobytes vicinity. My hypothesis was that vmware bridge filter dumps virtual cable segment traffic into the physical interface network stack at an enormous rate for a 100 Mbps connection, and the OS sees this traffic as coming from the physical card driver.  I decided to reconfigure the host network to “disclose” the virtual cable segment traffic to the OS using Windows MAC bridging instead of vmware “behind the scenes” bridging.  I can neither confirm nor deny the correctness of this hypothesis, but in practice it resolved the issue.


I am assuming that you are using bridged configuration and one virtual network interface in each VM.
The procedure I performed was:
Shutdown all VMs that you are going to reconfigure.Run vmware virtual network utility,  create an adapter (I will be using VMnet1 exempli gratia, but any other one except VMnet0 will work), and disconnect it from DHCP by removing it from the list on the DHCP page.  Unbinding DHCP from this adapter is important to avoid network problems.According to the procedure at http://www.vmware.com/info?id=68, enable VMnet1 participation in a bridge:Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class and look for the key {4D36E972-E325-11CE-BFC1-08002bE10318}. Make sure it is the right key by selecting it and verifying that (Default) has the value `Network adapters’.
Under {4D36E972-E325-11CE-BFC1-08002bE10318}, there are subkeys 0000, 0001, 0002 and so forth. Select each subkey until you find the one that corresponds to the VMnet adapter in question. The correct key has the DriverDesc with value `VMware Virtual Ethernet Adapter …’.
Add a DWORD value called AllowBindingToMACBridge, and set it to 1.
Bridge the physical and the new virtual connection, and assign the bridge correct network properties.In the VMs, set network adapter configuration to `Custom’, then choose `VMnet1′ for the network.This configuration puts all VMs on a single virtual cable segment, bridged explicitly, from the host OS point of view, to the physical interface driver.  Although the VMnet1 connection speed is still reported as 100 Mbps, and bursts of traffic clearly exceed that value by at least an orders of magnitude, the spurious DOS detection does not occur any more, at least on the same test files that I used (up to 100 MB).
[Modified by Mitch Tulloch] – 12 Nov 2004

轉錄自：http://www.windowsnetworking.com/kbase/WindowsTips/Windows2000/AdminTips/Network/VMWareProblemWhenSavingLargeFiles.html

事件類型: 警告

事件來源: Srv

事件類別目錄: 無

事件識別碼: 2025

日期: 2010/12/3

時間: 上午 09:18:05

使用者: N/A

電腦: MIS206

描述:

伺服器偵測到用戶端 \\OX01OX01 嘗試給予拒絕服務攻擊，所以已經中斷連線。

請在 http://go.microsoft.com/fwlink/events.asp 查看說明及支援中心，以取得其他資訊。

資料:

0000: 00 00 00 00 02 00 48 00   ……H.

0008: 00 00 00 00 e9 07 00 80   ….é..€

0010: 00 00 00 00 22 00 00 c0   ….”..À

0018: 00 00 00 00 00 00 00 00   ……..

0020: 00 00 00 00 00 00 00 00   ……..

Hits: 0