Azure Virtual Network Frequently Asked Questions
Azure Virtual Network Frequently Asked Questions
questions (FAQ)
Virtual Network basics
What is an Azure Virtual Network (VNet)?
An Azure Virtual Network (VNet) is a representation of your own network in the cloud. It is
a logical isolation of the Azure cloud dedicated to your subscription. You can use VNets to
provision and manage virtual private networks (VPNs) in Azure and, optionally, link the
VNets with other VNets in Azure, or with your on-premises IT infrastructure to create hybrid
or cross-premises solutions. Each VNet you create has its own CIDR block, and can be linked
to other VNets and on-premises networks as long as the CIDR blocks do not overlap. You
also have control of DNS server settings for VNets, and segmentation of the VNet into
subnets.
Create a dedicated private cloud-only VNet Sometimes you don't require a cross-
premises configuration for your solution. When you create a VNet, your services and
VMs within your VNet can communicate directly and securely with each other in the
cloud. You can still configure endpoint connections for the VMs and services that
require Internet communication, as part of your solution.
Securely extend your data center With VNets, you can build traditional site-to-site
(S2S) VPNs to securely scale your datacenter capacity. S2S VPNs use IPSEC to
provide a secure connection between your corporate VPN gateway and Azure.
Enable hybrid cloud scenarios VNets give 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 documentation to get started. This content provides overview and
deployment information for all of the VNet features.
Yes. You can use a VNet without connecting it to your premises. For example, you could run
Microsoft Windows Server Active Directory domain controllers and SharePoint farms solely
in an Azure VNet.
Yes. You can deploy a WAN optimization network virtual appliance from several vendors
through the Azure Marketplace.
Configuration
What tools do I use to create a VNet?
Azure portal
PowerShell
Azure CLI
A network configuration file (netcfg - for classic VNets only). See the Configure a
VNet using a network configuration file article.
Yes. For more information about public IP address ranges, see Create a virtual network.
Public IP addresses are not directly accessible from the internet.
Yes. See Azure limits for details. Subnet address spaces cannot overlap one another.
Yes. Azure reserves some IP addresses within each subnet. The first and last IP addresses of
each subnet are reserved for protocol conformance, along with the x.x.x.1-x.x.x.3 addresses
of each subnet, which are used for Azure services.
How small and how large can VNets and subnets be?
The smallest supported subnet is /29, and the largest is /8 (using CIDR subnet definitions).
No. VNets are Layer-3 overlays. Azure does not support any Layer-2 semantics.
Yes. You can create a route table and associate it to a subnet. For more information about
routing in Azure, see Routing overview.
You can use TCP, UDP, and ICMP TCP/IP protocols within VNets. Unicast is supported
within VNets, with the exception of Dynamic Host Configuration Protocol (DHCP) via
Unicast (source port UDP/68 / destination port UDP/67). Multicast, broadcast, IP-in-IP
encapsulated packets, and Generic Routing Encapsulation (GRE) packets are blocked within
VNets.
No.
No.
Yes. Subnets can be added to VNets at any time as long as the subnet address range is not
part of another subnet and there is available space left in the virtual network's address range.
Yes. You can add, remove, expand, or shrink a subnet if there are no VMs or services
deployed within it.
Yes. You can add, remove, and modify the CIDR blocks used by a VNet.
Yes. All services deployed within a VNet can connect outbound to the internet. To learn
more about outbound internet connections in Azure, see Outbound connections. If you want
to connect inbound to a resource deployed through Resource Manager, the resource must
have a public IP address assigned to it. To learn more about public IP addresses, see Public IP
addresses. Every Azure Cloud Service deployed in Azure has a publicly addressable VIP
assigned to it. You define input endpoints for PaaS roles and endpoints for virtual machines
to enable these services to accept connections from the internet.
No. You cannot use IPv6 with VNets at this time. You can however, assign IPv6 addresses to
Azure load balancers to load balance virtual machines. For details, see Overview of IPv6 for
Azure Load Balancer.
Yes. You can connect one VNet to another VNet using either:
Use the decision table on the Name Resolution for VMs and Role Instances page to guide you
through all the DNS options available.
Yes. You can specify DNS server IP addresses in the VNet settings. The setting is applied as
the default DNS server(s) for all VMs in the VNet.
Yes. You can change the DNS server list for your VNet at any time. If you change your DNS
server list, you will need to restart each of the VMs in your VNet in order for them to pick up
the new DNS server.
Azure-provided DNS is a multi-tenant DNS service offered by Microsoft. Azure registers all
of your VMs and cloud service role instances in this service. This service provides name
resolution by hostname for VMs and role instances contained within the same cloud service,
and by FQDN for VMs and role instances in the same VNet. To learn more about DNS, see
Name Resolution for VMs and Cloud Services role instances.
There is a limitation to the first 100 cloud services in a VNet for cross-tenant name resolution
using Azure-provided DNS. If you are using your own DNS server, this limitation does not
apply.
No. You cannot specify a custom DNS suffix for your VNets.
Yes. All network interfaces (NIC) attached to a VM deployed through the Resource Manager
deployment model must be connected to a VNet. VMs deployed through the classic
deployment model can optionally be connected to a VNet.
Private: Assigned to each NIC within each VM. The address is assigned using either
the static or dynamic method. Private IP addresses are assigned from the range that
you specified in the subnet settings of your VNet. Resources deployed through the
classic deployment model are assigned private IP addresses, even if they're not
connected to a VNet. The behavior of the allocation method is different depending on
whether a resource was deployed with the Resource Manager or classic deployment
model:
o Resource Manager: A private IP address assigned with the dynamic or static
method remains assigned to a virtual machine (Resource Manager) until the
resource is deleted. The difference is that you select the address to assign
when using static, and Azure chooses when using dynamic.
o Classic: A private IP address assigned with the dynamic method may change
when a virtual machine (classic) VM is restarted after having been in the
stopped (deallocated) state. If you need to ensure that the private IP address
for a resource deployed through the classic deployment model never changes,
assign a private IP address with the static method.
Public: Optionally assigned to NICs attached to VMs deployed through the Azure
Resource Manager deployment model. The address can be assigned with the static or
dynamic allocation method. All VMs and Cloud Services role instances deployed
through the classic deployment model exist within a cloud service, which is assigned
a dynamic, public virtual IP (VIP) address. A public static IP address, called a
Reserved IP address, can optionally be assigned as a VIP. You can assign public IP
addresses to individual VMs or Cloud Services role instances deployed through the
classic deployment model. These addresses are called Instance level public IP (ILPIP
addresses and can be assigned dynamically.
Can I reserve a private IP address for a VM that I will create at a later time?
No. You cannot reserve a private IP address. If a private IP address is available, it is assigned
to a VM or role instance by the DHCP server. The VM may or may not be the one that you
want the private IP address assigned to. You can, however, change the private IP address of
an already created VM, to any available private IP address.
Do private IP addresses change for VMs in a VNet?
It depends. If the VM was deployed through Resource Manager, no, regardless of whether the
IP address was assigned with the static or dynamic allocation method. If the VM was
deployed through the classic deployment model, dynamic IP addresses can change when a
VM is started after having been in the stopped (deallocated) state. The address is released
from a VM deployed through either deployment model when the VM is deleted.
Yes, but it's not recommended unless necessary, such as when assigning multiple IP
addresses to a virtual machine. For details, see Adding multiple IP addresses to a virtual
machine. If the IP address assigned to an Azure NIC attached to a VM changes, and the IP
address within the VM operating system is different, you lose connectivity to the VM.
Nothing. The IP addresses (public VIP, public, and private) remain assigned to the cloud
service deployment slot or VM.
Can I move VMs from one subnet to another subnet in a VNet without
redeploying?
Yes. You can find more information in the How to move a VM or role instance to a different
subnet article.
Will the MAC address remain the same for my VM once it's created?
Yes, the MAC address remains the same for a VM deployed through both the Resource
Manager and classic deployment models until it's deleted. Previously, the MAC address was
released if the VM was stopped (deallocated), but now the MAC address is retained even
when the VM is in the deallocated state.
Yes. All VMs and Cloud Services role instances deployed within a VNet can connect to the
Internet.
Can I deploy Cloud Services with web and worker roles (PaaS) in a VNet?
Yes. You can (optionally) deploy Cloud Services role instances within VNets. To do so, you
specify the VNet 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.
Is there a complete list of Azure services that can I deploy resources from into
a VNet?
Yes, For details, see Virtual network integration for Azure services.
Resources deployed through some Azure PaaS services (such as Azure Storage and Azure
SQL Database), can restrict network access to only resources in a VNet through the use of
virtual network service endpoints. For details, see Virtual network service endpoints
overview.
No. You cannot move services in and out of VNets. To move a resource to another VNet, you
have to delete and redeploy the resource.
Security
What is the security model for VNets?
VNets are isolated from one another, and other services hosted in the Azure infrastructure. A
VNet is a trust boundary.
Yes. You can apply Network Security Groups to individual subnets within a VNet, NICs
attached to a VNet, or both.
Yes. You can use REST APIs for VNets in the Azure Resource Manager and classic (Service
Management) deployment models.
The Azure portal to deploy VNets through the Azure Resource Manager and classic
deployment models.
PowerShell to manage VNets deployed through the Resource Manager and classic
deployment models.
The Azure command-line interface (CLI) to deploy and manage VNets deployed
through the Resource Manager and classic deployment models.