Windows Server 2008 R2, fully patched and updated.
I have 4 static IPs on a dedicated server. I will refer to them as follows:
x.x.x.x
y.y.y.y
z.z.z.z
a.a.a.a
x.x.x.x is the default external and internal IP address of the server.
All external IPs are the same as the internal IPs, all running on the same NIC.
x.x.x.x and y.y.y.y were running on port 80 for HTTP through IIS, with different host headers handling the destinations. That worked perfectly.
I recently added two new IP addresses, z.z.z.z and a.a.a.a for a different application that uses two ports, but we want external port 80 traffic to translate to the internal ports it is using.
We want incoming traffic to work as follows:
Incoming traffic on x.x.x.x:80 map to x.x.x.x:8080
Incoming traffic on y.y.y.y:80 map to y.y.y.y:8080
Incoming traffic on z.z.z.z:80 map to y.y.y.y:8088
Incoming traffic on a.a.a.a:80 map to y.y.y.y:8089
We changed the binding in IIS to only listen on the specific IPs and internal ports so that port 80 was only being listened to by netsh portproxy.
We have been able to accomplish this with 4 separate netsh portproxy rules and everything works great. All traffic to the two HTTP IPs works fine, and the traffic for the other two IPs to the other two internal ports get routed properly as well.
The problem is that everything works as expected, but occasionally something hangs, usually around 4 PM EST, and the websites are no longer available. There are no application pool or website crashes. Just ports no longer routing.
When it hangs the easiest fix is to run "portproxy reset" and re-create the portproxy rules through a batch file and everything works again.
I guess my question is if there is some kind of idle timeout built into netsh portproxy or possibly some type of buffer overrun protection.
Not a single log shows any faults.
The application pools in IIS were adjusted to recycle at shorter intervals (30 minutes) to prevent any long running worker processes in case that was the issue. Same result.
I can easily create a Windows service to check the port status at a very short interval and reset the specific portproxy rule, but this is not ideal, as there is still the potential for packet loss and unavailability of the services (even if for only a few seconds) requiring the HTTP requests to be re-sent.
Again, I should reiterate that everything works great until a certain point in the day, and that this has absolutely nothing to do with the Windows Firewall, as we get the exact same results with it on or off. There are no apparent DDoS or other types of attacks either. All separate websites and other applications still run on their internal ports when the portproxy hangs (i.e. accessing http://example.com:8080 still works without issue).
The point of failure is the netsh portproxy.
Has anyone experienced similar issues? I am considering adding a Fortinet hardware firewall that has this functionality built in, but I am wondering if that will handle it any better than what is already in place.
