Optionally allow virtual servers a direct connection to the Internet, NAT is too limiting
Forcing NAT for every VM makes it much more difficult to build Highly Available systems using Azure.
IPSec is the most common way to secure communications across the Internet and is often used in IaaS when setting up highly available services.
For example, if I want to replicate MongoDB from US EAST to US WEST, using IPSec between the two VMs is the easiest way to accomplish that.
But Azure forces NAT for every VM making it impossible to use IPSec.
Thanks for the feedback.
Although we will be working on providing a dedicated NAT IP address for a virtual machine we will not be routing the traffic directly to the VM, it will still go through Azure’s NAT device.
For high availability, Azure offers free load balancing on a cloud service. You can put 1 or more instances behind a public IP and can take advantage of the load balancing Azure provides to customers as a basic service.
I will be interested to know if that does not solve a particular scenario.
Charlie Offenbacher commented
+1 To Eric's points.
Eric Blevins commented
Load balancing is not a source of concern, NAT transversal is the problem.
There are some protocols that do not work well through NAT.
By forcing everyone through NAT you are limiting what can be done within Azure.
Using IPSec as an example, there is a KB article that says one should not use IPSec NAT-T on the server side:
Another more recent KB article says "you may experience unexpected results when you put a server behind a NAT device and then use an IPsec NAT-T environment. Therefore, if you must have IPsec for communication, we recommend that you use public IP addresses for all servers that you can connect to from the Internet."
Seems really odd that Azure cannot provide the exact thing that Microsoft recommends we use.