Virtual Network FAQ
Updated: June 19, 2015
Virtual Network lets you provision and manage virtual private networks (VPNs) in Azure and, optionally, link the VPNs with your on-premises IT infrastructure to create hybrid and cross-premises solutions. With Virtual Network, IT administrators can control network topology, including configuration of DNS and IP address ranges.
For more information, see Virtual Network Overview.
Use Virtual Network to:
Create a dedicated private cloud-only virtual network
Sometimes you don’t require a cross-premises configuration for your solution. When you create a virtual network, your services and VMs within your virtual network can communicate directly and securely with each other in the cloud. This keeps traffic securely within the virtual network, but still allows you to configure endpoint connections for the VMs and services that require Internet communication as part of your solution.
Securely extend your data center
With Virtual Network, you can build traditional site-to-site VPNs to securely scale your datacenter capacity. Virtual Network uses industry-standard IPSEC protocol to provide a secure connection between your corporate VPN gateway and Azure. Add as many machines as you want behind the VPN gateway.
Enable hybrid cloud scenarios
Virtual Network gives you the flexibility to support a range of hybrid cloud scenarios. You can securely connect cloud-based applications to any type of on-premises system such as mainframes and Unix systems.
Visit the Virtual Network Overview to see a decision table that will help you decide the best network design option for you.
We have a Resources page that can help get you started. This page has links to common configuration steps as well as information that will help you understand the things that you’ll need to take into consideration when designing your virtual network.
Virtual Network can be used with a variety of different Azure services, such as Cloud Services (PaaS), Virtual Machines, and Web Apps. However, there are a few services that are not supported on Virtual Network. Please check the specific service you want to use and verify that it is compatible.
Yes. Virtual Network can be used without using site-to-site connectivity. This is particularly useful if you want to run domain controllers and SharePoint farms in Azure.
You can use the following tools to create or configure a virtual network:
You can use the Management Portal. See About Virtual Network Settings in the Management Portal.
You can use a network configuration file (netcfg). See Configure a Virtual Network Using a Network Configuration File.
You can use public IP address ranges and any IP address range defined in RFC1918.
Yes. For more information about public IP address ranges, see About Public IP Address Space and Virtual Network.
There is no limit on the number of subnets you use within a virtual network. All the subnets must be fully contained in the virtual network address space and should not overlap with one another.
We do reserve some IP addresses within each subnet. The first and last IP addresses of the subnets are reserved for protocol conformance. We also additionally reserve a few extra IP addresses for our services.
The smallest subnet we support is a /29 and the largest is a /8 (using CIDR subnet definitions). We reserve some IP addresses from each subnet.
Virtual Networks are Layer-3 overlays. We do not support any Layer – 2 semantics.
No. We do not support custom routing policies with virtual networks.
No. We do not support multicast or broadcast.
We support standard IP-based protocols within the virtual network. We however block multicast, broadcast, IP-in-IP encapsulated packets and Generic Routing Encapsulation (GRE) packets. Standard protocols that work include:
No. We do not support pinging the default gateway of a subnet.
Subnets can be added to virtual networks at any time as long as the subnet address is not part of another subnet in the virtual network.
You can add, remove, expand or shrink a subnet if there are no VMs or services deployed within it by using PowerShell cmdlets or the NETCFG file. You can also add, remove, expand or shrink any prefixes as long as the subnets that contain VMs or services are not affected by the change.
You can modify the subnet addresses as long as there are no services or VMs deployed within them by using PowerShell cmdlets or the NETCFG file. You cannot modify or delete a subnet once services or VMs have been deployed to it.
Yes. All services deployed within a virtual network can connect to the internet. Every cloud service deployed in Azure has a publicly addressable VIP assigned to it. You will have to define input endpoints for PaaS roles and endpoints for virtual machines to enable these services to accept connections from the internet.
No. We do not support IPv6 with virtual networks.
No. A virtual network is limited to a single region.
For the latest FAQ on virtual network VPNs, see the VPN Gateway FAQ.
Yes. You can specify DNS server IP addresses in the virtual network definition. This will be applied as the default DNS server(s) for all virtual machines in the virtual network.
You can specify up to 12 DNS servers.
Yes. You can change the DNS server list for your virtual network at any time. If you change your DNS server list, you will need to restart each of the virtual machines in your virtual network in order for them to pick up the new DNS server.
Use the decision table on the Name Resolution for VMs and Role Instances page to guide you through all the DNS options available.
Azure-provided DNS is a multi-tenant DNS service offered by us. We register all of your virtual machines in this service. This service provides name resolution by hostname for VMs contained within the same cloud service, and by FQDN for VMs in the same virtual network. Note: There is a limitation at this time to the first 100 cloud services in the virtual network for cross-tenant name resolution using Azure-provided DNS. If you are using your own DNS server, this limitation does not apply.
Yes. You can set DNS servers on a per-cloud service basis to override the default network settings. However, we recommend that you use network-wide DNS as much as possible.
No. We do not support the ability to specify a custom DNS suffix for your virtual networks.
We support all Linux distros that are supported in by Azure.
An internal IP address (DIP) is an IP address that is assigned to each virtual machine by DHCP. It’s not public facing. If you have created a virtual network, the internal IP address is assigned from the range that you specify. If you do not have a virtual network, an internal IP address will still be assigned. The internal IP address will remain with the virtual machine for its lifetime, unless that virtual machine is Stop (Deallocated).
A public VIP is the public IP address that is assigned to your cloud service. It is not assigned directly to your virtual machine NIC. The VIP stays with the cloud service it is assigned to until all the virtual machines in that cloud service are all Stop (Deallocated) or deleted. At that point, it is released.
DIP - If you deploy a VM to a virtual network, the VM always receives an internal IP address (DIP) from a pool of internal IP addresses that you specify. VMs communicate within the virtual network by using DIPs. Although Azure assigns the DIP, you can request a static DIP for your virtual machine if you deploy the VM using PowerShell. See Set a Static Internal IP Address for a VM.
VIP - Your VM is also associated with a VIP, although a VIP is never assigned to the VM directly. A VIP is a public IP address that can be assigned to your cloud service. You can, optionally, reserve a VIP for your cloud service. See Reserved Public IP.
PIP - Your VM can, optionally, also receive an instance-level public IP address (PIP). The PIP is directly associated with the VM, rather than the cloud service. PIP is currently in Preview. See Instance-level Public IP Address (PIP).
Azure will use DHCP to assign an internal IP address to each VM and PaaS instance from the subnet you specify.
Yes. In order to specify the DIP, you’ll need to create your VM using PowerShell cmdlets. There are cmdlets that allow you to specify the DIP that your virtual machine will receive. You’ll need to verify that the DIP that you specify is not being used by another VM or service in your virtual network. When you specify a DIP, it will stay with your virtual machine for its lifetime – even if you Stop (Deallocate) it. If you start the virtual machine again after Stop (Deallocate), it will use the DIP that was previously specified. You don’t need to specify the DIP for a virtual machine unless you require that functionality.
No. You can’t reserve a DIP. If a DIP is available, it’s able to be assigned to a VM by the DHCP server. That VM may or may not be the one that you want the DIP to be assigned to. You can, however, change the DIP of an already created VM to an available address by using PowerShell. At that point, when the desired DIP becomes available in the system, you can then specify it when you create the new VM. You can also release a DIP from a VM by using PowerShell. If you release a DIP, the VM will be assigned a new DIP.
Internal IP addresses remain with the virtual machine for its lifetime unless the VM is Stop (Deallocated). When a VM is Stop (Deallocated), the internal IP address is released unless you defined a static DIP by using PowerShell. If the VM is simply stopped (and not put in the status “Stopped (Deallocated)”) the IP address will remain assigned to the virtual machine.
No. You must not change any interface properties of VMs. Any changes may lead to potentially losing connectivity to the virtual machine.
Nothing. The IP addresses (both public VIP and internal DIP) will stay with your cloud service or virtual machine. Note: if you want to simply shut down the virtual machine, don’t use the Management Portal to do so. Currently, the shutdown button will Stop (Deallocate) the virtual machine.
Stop (Deallocated) is a status that you can specify in the Management Portal by selected to Shut Down the virtual machine. It is different from simply shutting down a virtual machine from inside the virtual machine itself. When you Stop (Deallocate) a virtual machine, you are not only stopping the VM, you are also specifying to release the internal IP address, as well as the public VIP address (if no other VMs are using the public VIP, as the VIP is assigned to the cloud service and not directly to the virtual machine). When you re-allocate the virtual machine, it will then pick up a new public VIP (if it is not joining a cloud service that already has one) as well as a new internal IP address.
The only way to keep the DIP of a virtual machine through a Stop (Deallocated) status is to define a static IP address for that virtual machine. If you find that you have Stop (Deallocated) the virtual machine, but you want the original DIP, you can specify it when you redeploy the VM by using PowerShell if the DIP hasn’t already been assigned to another VM in your virtual network.
Yes. You can use PowerShell to do so. You can find more information here.
No. A MAC address cannot be statically configured.
No. A virtual machine’s MAC address can change for a few different reasons. If the VM is put in the status Stopped (Deallocated), if you change the virtual machine size, or if there is service healing or planned maintenance of the host server, the MAC address is not retained.
Yes. All services deployed within a virtual network can connect to the internet. Additionally, every cloud service deployed in Azure has a publicly addressable VIP assigned to it. You will have to define input endpoints for PaaS roles and endpoints for virtual machines to enable these services to accept connections from the internet.
We support only compute services within virtual networks. Compute services are limited to Cloud Services (web and worker roles) and virtual machines.
An Azure Website cannot be deployed in a VNet. However, Web Apps can securely connect and access resources in your Azure VNet if you have point-to-site configured for your virtual network.
For more information, see the following:
No. We do not support SQL DBs with virtual networks.
Yes. You can deploy PaaS services within virtual networks. You can accomplish this without changing any code.
You can accomplish this by specifying the virtual network name and the role /subnet mappings in the network configuration section of your service configuration. You do not need to update any of your binaries.
No. We do not support the ability to move services in and out of virtual networks. You will have to delete and re-deploy the service into virtual networks.
Azure uses DHCP to assign an internal IP address to each virtual machine and PaaS instance from the virtual network subnet you specify.
Virtual networks are completely isolated from one another and other services hosted in the Azure infrastructure. Trust boundary = virtual network boundary.
No. We do not support ACLs for subnets within virtual networks. However, ACLs can be defined on input endpoints for virtual machines that have been deployed to a virtual network. Note: a virtual machine does not have to be deployed to a virtual network in order to define an ACL for the input endpoint.
Yes. We have REST APIs to manage virtual networks and cross-premises connectivity. More information can be found here.
Yes. We have PowerShell and command line tools for a variety of platforms. More information can be found here.