Issue resolving names on Hyper-V guest with Routing and Remote Access

This VM subsequently had HD issues, so I will chalk this one up to data corruption wonkiness.

I believe that the Microsoft NAT implementation suffers from an artifact that many NAT implementations do (older Cisco PIXOS, Linux ipchains-- the precursor to iptables) in that NAT only occurs on traffic arriving on the "public" interface. The Cisco-ism for this behavior is "hairpinning" (I guess because the packet makes a "hairpin turn" and leaves through the interface it entered on).

Here's an analagous problem:

A Customer has a Cisco PIX at the edge of their network doing NAT between a public static IP address and their LAN. They've got an HTTP server on the LAN at 192.168.1.1, and their public IP is 172.18.9.1. A request from a browser running on a PC on the LAN to "http://172.18.9.1" returns "The page could not be displayed" because the PIX NAT implementation does not NAT the traffic arriving on the internal interface bound for 172.18.9.1 to 192.168.1.1.

Here's a Server Fault question that also describes the behaviour I'm talking about (albeit, again, not specifically citing Microsoft's NAT implementation): Unable to connect on natted server from a host computer on the same LAN using public IP address

I believe you're seeing a similar behaviour with Microsoft's NAT implementation, but I don't have hard evidence (i.e. documentation from Microsoft). I don't have the resources to spin up a test machine at hand, and Microsoft doesn't seem to be using the "hairpin" keyword in their documentation to the positive or negative.

(I actually find it rather funny, in that Server Fault question that I reference above, that people consider a lack of "hairpinning" to be "normal". Linux iptables would handle what you're doing w/ no problem. I've always considered NAT implementations that can't handle this "hairpinning" to be inferior.)