Export (0) Print
Expand All

Virtual Network FAQ

Updated: July 28, 2014

Virtual Network Basics

Virtual Network Configuration

Virtual Network Cross-premises Connectivity (VPNs)

Multi-Site and VNet-to-VNet Connectivity

Virtual Network and Name Resolution (DNS)

Virtual Network and Virtual Machines

Virtual Network and Services

Virtual Network and Security

APIs, Schemas, and Tools

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 Cloud Services (PaaS) and virtual machines. Virtual Network cannot be used for any other services at this time.

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 any IP address range defined in RFC1918. This includes IP addresses in the following ranges:

  • 10.0.0.0 - 10.255.255.255 (10/8 prefix)

  • 172.16.0.0 - 172.31.255.255 (172.16/12 prefix)

  • 192.168.0.0 - 192.168.255.255 (192.168/16 prefix)

IP addresses outside the RFC1918 range are not supported.

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:

  • TCP

  • UDP

  • ICMP

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.

Yes. You can create VNet to VNet communication by using REST APIs or Windows PowerShell. See Configure a VNet to VNet Connection.

Virtual Network supports the following cross-premises connections:

  • Site-to-site – VPN connection over IPsec (IKE v1 and IKE v2)

  • Point-to-site – VPN connection over SSTP (Secure Sockets Tunneling Protocol)

  • ExpressRoute – direct secure connection from your WAN, not over the public Internet

Site-to-site connections let you connect between any of the computers located on your premises to any virtual machine or role instance within your virtual network, depending on how you choose to configure routing. It’s a great option for an always-available cross-premises connection and is well-suited for hybrid configurations. It relies on an IPsec VPN appliance (hardware or soft appliance) to be deployed at the edge of your network for connectivity. In order to create this type of connection, you’ll have to have the required VPN hardware and an externally facing IPv4 IP address.

Point-to-site connections let you connect from a single computer to anything located in your virtual network. It uses the Windows VPN client. As part of the point-to-site configuration, you install a certificate and a VPN client configuration package, which contains the settings that allow your computer to connect to any virtual machine or role instance within the virtual network. It’s great when you want to connect to a virtual network, but aren’t located on-premises. It’s also a good option when you don’t have access to VPN hardware or an externally facing IPv4 IP address, both of which are required for a site-to-site connection.

Note: You can configure your virtual network to use both site-to-site and point-to-site concurrently, provided that you create your site-to-site connection using a dynamic gateway. For more information, see About Secure Cross-Premises Connectivity.

You can connect to multiple sites by using Windows PowerShell and the Azure REST APIs. See the Multi-Site and VNet-to-VNet Connectivity FAQ section.

We have validated a set of standard site-to-site VPN devices in partnership with device vendors. A list of known compatible VPN devices, their corresponding configuration templates, and device specs can be found here. All devices in the device families listed as known compatible should work with Virtual Network. To help configure your VPN device, refer to the device configuration template that corresponds to appropriate device family.

If you do not see your device listed as a known compatible VPN device and want to use it for your VPN connection, you’ll need to verify that it meets the minimum requirements. Devices meeting the minimum requirements should also work well with Virtual Network. Minimum device requirements are listed below for both static and dynamic route configurations. More information can be found here. Please contact your device manufacturer for additional support and configuration instructions.

We support Windows Server 2012 Routing and Remote Access (RRAS) servers for site-to-site cross-premises configuration.

Other software VPN solutions should work with our gateway as long as they conform to industry standard IPsec implementations. Contact the vendor of the software for configuration and support instructions.

The following operating systems are supported:

  • Windows 7 (64-bit version only)

  • Windows Server 2008 R2

  • Windows 8 (64-bit version only)

  • Windows Server 2012

No. Support is limited only to the Windows operating system versions listed above.

We support up to 128 VPN clients to be able to connect to a virtual network.

At this time, only self-signed root certificates are supported.

Yes. We use SSTP (Secure Sockets Tunneling Protocol) to tunnel through firewalls. This tunnel will appear as a HTTPs connection.

By default, the client computer will not reestablish the VPN connection automatically.

Auto-reconnect and DDNS are currently not supported in point-to-site VPNs.

Yes. Both these solutions will work if you have a dynamic-routing VPN gateway for your virtual network. We do not support point-to-site in static-routing VPN gateways.

Yes, it is possible. But the virtual networks cannot have overlapping IP prefixes and the point-to-site address spaces must not overlap between the virtual networks.

It’s difficult to determine the exact throughput through the VPN tunnels. IPsec and SSTP are crypto-heavy VPN protocols. Throughput is also limited by the latency and bandwidth between your premises and the internet.

Static routing VPNs are also referred to as policy-based VPNs. Policy-based VPNs encrypt and route packets through an interface based on a customer-defined policy. The policy is usually defined as an access list.

Dynamic routing VPNs are also referred to as route-based VPNs. Route-based VPNs depend on a tunnel interface specifically created for forwarding packets. Any packet arriving on the tunnel interface will be forwarded through the VPN connection.

No. You have to create your gateway first to get the IP address. The IP address will change if you delete and re-create your VPN gateway.

We generate a pre-shared key (PSK) when we create the VPN gateway. You must use the PSK to authenticate. The PSK can be re-generated at any time and the PSK length can be changed as needed.

Yes, the Set Pre-Shared Key API and PowerShell cmdlet can be used to configure both Azure static routing VPN and dynamic routing VPNs.

We are limited to using pre-shared keys (PSK) for authentication.

We have a gateway service that we run to enable cross-premises connectivity. We need 2 IP addresses from your routing domain for us to enable routing between your premises and the cloud. We require you to specify at least a /29 subnet from which we can pick IP addresses for setting up routes.

Please note that you must not deploy virtual machines or role instances in the gateway subnet.

Add each range that you want sent through the gateway for your virtual network on the Networks page under Local Networks.

No. We do not support configuring routes. You will have to use the virtual network gateway for cross-premises connectivity.

Yes, it is protected by IPsec/IKE encryption.

Max. 10 combined. For example, one Azure virtual network can connect to 6 on-premises sites and 4 virtual networks.

Yes, the P2S VPNs can be used with the VPN gateways connecting to multiple on premises sites and other virtual networks

No, redundant tunnels between an Azure virtual network and an on premises site is not supported.

No, overlapping address spaces will cause the NETCFG upload or creating virtual network to fail.

No, all VPN tunnels, including P2S VPNs, share the same Azure VPN gateway and the available bandwidth.

Transit traffic via Azure VPN gateway is possible, but rely on statically defined address spaces in the NETCFG configuration file. BGP is not yet supported with Azure Virtual Networks and VPN gateways. Without BGP, manually defining transit address spaces in NETCFG is very error prone, and not recommended.

Yes. In fact, there is no region constraint. One virtual network can connect to another virtual network in the same region, or in different Azure region.

No, Azure by default generates different pre-shared keys for different VPN connections. However, you can use the newly introduced Set VPN Gateway Key REST API or PowerShell cmdlet to set the key value you prefer. The key MUST be alphanumerical string of length between 1 to 128 characters.

Azure charges only for traffic traversing from one Azure region to another. The traffic is charged based on the same rate as the egress data transfer charge listed in the Azure pricing page.

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 (DNS) 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 Configure a Static Internal IP Address (DIP) 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 IP Addresses.

  • 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 Addresses.

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.

You can do either. If you have RDP enabled and you have created an endpoint, you can connect to your virtual machine by using the VIP. In that case, you would specify the VIP and the port that you want to connect to. You’ll need to configure the port on your virtual machine for the traffic. Typically, you would go to the Management Portal and save the settings for the RDP connection to your computer. The settings will contain the necessary connection information.

If you have a virtual network with cross-premises connectivity configured, you can connect to your virtual machine by using the internal DIP. You can also connect to your virtual machine by internal DIP from another virtual machine that’s located on the same virtual network. You can’t RDP to your virtual machine by using the DIP if you are connecting from a location outside of your virtual network. For example, if you have a point-to-site virtual network configured and you don’t establish a connection from your computer, you can’t connect to the virtual machine by DIP.

No. Only the traffic that has a destination IP that is contained in the virtual network Local Network IP address ranges that you specified will go through the virtual network gateway. Traffic has a destination IP located within the virtual network will stay within the virtual network. Other traffic is sent through the load balancer to the public networks. If you are troubleshooting, it’s important to make sure that you have all the ranges listed in your Local Network that you want to send through the gateway. Verify that the Local Network address ranges do not overlap with any of the address ranges in the virtual network. Also, you’ll want to verify that the DNS server you are using is resolving the name to the proper IP address.

We support only compute services within virtual networks. Compute services are limited to Cloud Services (web and worker roles) and virtual machines.

No. We do not support websites with virtual networks.

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.

See Also

Show:
© 2014 Microsoft