Azure Virtual Network Frequently Asked Questions
Azure Virtual Network Frequently Asked Questions
questions (FAQ)
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.
Can I perform WAN optimization between VNets or a VNet and my on-
premises data center?
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.
Can I specify custom routing policies on my VNets and subnets?
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.
Can I ping my default routers within a VNet?
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.
No. A VNet is limited to a single region. A virtual network does, however, span
availability zones. To learn more about availability zones, see Availability zones
overview. You can connect virtual networks in different regions with virtual network
peering. For details, see Virtual network peering overview
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.
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.
Yes. You can set DNS servers per VM or cloud service to override the default network
settings. However, it's recommended that you use network-wide DNS as much as
possible.
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.
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.
If I stop a Cloud Service deployment slot or shutdown a VM from
within the operating system, what happens to my IP addresses?
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 subnetarticle.
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.
Yes. You can deploy Web Apps inside a VNet using an ASE (App Service
Environment). If you have a point-to-site connection configured for your VNet, all
Web Apps can securely connect and access resources in the VNet. For more
information, see the following articles:
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.
Can I connect a Virtual Machine Scale Set (VMSS) to 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
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.
VNet peering
VNet peering (or virtual network peering) enables you to connect virtual networks. A
VNet peering connection between virtual networks enables you to route traffic
between them privately through IPv4 addresses. Virtual machines in the peered
VNets can communicate with each other as if they are within the same network.
These virtual networks can be in the same region or in different regions (also known
as Global VNet Peering). VNet peering connections can also be created across Azure
subscriptions.
Yes. Global VNet peering enables you to peer VNets in different regions. Global VNet
peering is available in all Azure public regions. You cannot globally peer from Azure
public regions to National clouds. Global peering is not currently available in national
clouds.
If your peering connection is in an Initiated state, this means you have created only
one link. A bidirectional link must be created in order to establish a successfuly
connection. For example, to peer VNet A to VNet B, a link must be created from
VNetA to VNetB and from VNetB to VNetA. Creating both links will change the state
to Connected.
If your VNet peering connection is in a Disconnected state, it means one of the links
created was deleted. In order to re-establish a peering connection, you will need to
delete the link and recreate.
Yes. You can peer VNets across subscriptions and across regions.
There is no charge for creating a VNet peering connection. Data transfer across
peering connections is charged. See here.
No. Traffic between resources in peered VNets is private and isolated. It remains
completely on the Microsoft Backbone.
If I peer VNetA to VNetB and I peer VNetB to VNetC, does that mean
VNetA and VNetC are peered?
No. Transitive peering is not supported. You must peer VNetA and VNetC for this to
take place.
No. VNet peering, whether local or global, does not impose any bandwidth
restrictions. Bandwidth is only limits by the VM or compute resource.
During developer preview, the capability is available in the West Central US region.
The monitored network interfaces , the virtual network TAP resource, and the
collector or analytics solution must be deployed in the same region.
Filtering capabilities are not supported with the virtual network TAP preview. When a
TAP configuration is added to a network interface a deep copy of all the ingress and
egress traffic on the network interface is streamed to the TAP destination.
A monitored network interface can have only one TAP configuration. Check with the
individual partner solutions for the capability to stream multiple copies of the TAP
traffic to the analytics tools of your choice.
Can the same virtual network TAP resource aggregate traffic from
monitored network interfaces in more than one virtual network?
Yes. The same virtual network TAP resource can be used to aggregate mirrored traffic
from monitored network interfaces in peered virtual networks in the same
subscription or a different subscription. The virtual network TAP resource and the
destination load balancer or destination network interface must be in the same
subscription. All subscriptions must be under the same Azure Active Directory tenant.
Virtual network TAP is in developer preview. During preview, there is no service level
agreement. The capability should not be used for production workloads. When a
virtual machine network interface is enabled with a TAP configuration, the same
resources on the azure host allocated to the virtual machine to send the production
traffic is used to perform the mirroring function and send the mirrored packets.
Select the correct Linux or Windows virtual machine size to ensure that sufficient
resources are available for the virtual machine to send the production traffic and the
mirrored traffic.