deprovision the virtual machine, such as shutting it down from the Microsoft Azure
management portal, because this will result in the virtual machine getting a new
virtual network adapter and a new MAC when it is subsequently started, and therefore
a new IP address. If you want to ensure that your virtual machine’s private IP address
never changes, configure its private IP address as static, which tells the Azure fabric
always to give the VM the same IP address even if it has been deprovisioned. If you
leverage static private IP addresses, the best practice is to have a subnet just for IP
addresses that will be statically assigned rather than mixing them in a subnet that also
dynamically assigns IP addresses.
Within a virtual network, most IP-based protocols—such as TCP, UDP, and ICMP—
will work. However, multicast, broadcast, IP-in-IP encapsulated packets, and GRE
packets are blocked. The GRE blocking is logical when you consider that behind the
scenes Microsoft Azure is leveraging Hyper-V Network Virtualization, which itself
uses GRE.
This really is all a virtual network is. You have an IP address space that you define and
then divide into subnets, and virtual machines are then assigned to the subnets when
they are created. You cannot move existing virtual machines into a virtual network or
move a virtual machine out of a virtual network without deleting and re-creating the
VM. Note that the subnet the VM is in can be changed. The virtual network
configuration must be done at the time of virtual machine creation. I am referring
exclusively to virtual machines, but PaaS web and worker roles can also leverage
virtual networks.
If you have multiple virtual networks and you want the VMs in those networks to be
able to communicate, you have to link them together. This can be done through the
site-to-site VPN or ExpressRoute (as covered in the next section), but instead of
connecting a virtual network to on premises, you simply connect multiple virtual
networks.
Linking On-Premises Networks with Azure IaaS
I previously discussed public IP addresses, which are Internet-accessible addresses
that can be assigned directly to VMs or to a load balancer that can distribute traffic
between VMs. A public IP can be dynamic or static in nature, and it can have an
optional DNS name to reference it. Using a public IP address, services can be
published out to the Internet. If a VM is created through the Azure portal by default, a
public IP is added, and the automatic Network Security Group that is created, which
restricts the types of traffic, has an exception for RDP traffic that enables connectivity
to the VM via the Internet. However, this is added only as a “lowest common
denominator” action to ensure that people can connect to their VM. In the real world,
very few services should publish RDP out to the Internet; instead, the services should
be connected to via a secure link between an organization’s on-premises network and
the Azure virtual network. This enhances security and removes the need to have
public IPs, except in cases where a service needs explicitly to be published to the