We are having a weird issue with a Windows 2008 DCE Server running a Windows 2003 R2 SP2 x32 Server in a Hyper-V instance behind RRAS.
Essentially, this server stops receiving inbound traffic through RRAS periodically. Connecting to the server via Hyper-V manager and disconnecting and reconnecting the NIC allows inbound traffic to work again.
More details on the setup: The server is a Windows 2008 Data Center Edition x64 with SP1. This server has a number of external IP's associated with it by our ISP. Because the ISP ties IP's to MAC's, we use RRAS with NAT to map the external IP to an internal IP on a Hyper-V server. For example, we have a Hyper-V Virtual Network on 192.168.1.X, with the server being 192.168.1.1 and a hyper-V instance having an IP of 192.168.1.11. Then in RRAS, we create a reservation through NAT to map the external IP to that internal IP.
Although it may not be relevant, there is also a separate 192.168.0.X network that links this server with another server (a private network through the ISP). We use the 192.168.0.X network for fast communication between the VM's on both Hyper-V servers.
This setup has been working fine for the rest of the VM's (including another Windows 2003 x32 setup), but for some reason this particular Windows 2003 VM likes to stop accepting inbound traffic through RRAS every so often (about every 10 hours, but not regularly).
When this happens, the VM is still pingable from the Hyper-V server using the 192.168.1.X, but it is not pingable from the outside. So I suspect the conflict has something to do with RRAS in this setup.
I've Googled various related keywords, and found some posts referencing issues with Windows 2003 SP2 and RRAS, specifically with security settings in TCP/IP. Supposedly there are some advanced security features in SP2 where it is extra careful with how it treats routed traffic. I have installed the related hotfix and double-check the registry setting, but this does not seem to fix the issue.
Any ideas?
This VM subsequently had HD issues, so I will chalk this one up to data corruption wonkiness.