Virtual machines are assigned an address configuration from the address space of the subnet by DHCP:
Address/subnet mask
Default gateway
DNS server IP addresses
You can also reserve a static IP address.
Virtual machines can also be assigned a public IP address
The Azure gateway subnet is needed by Azure to host the two virtual machines of your Azure gateway. Specify an address space with at least a 29-bit prefix length (example: 192.168.15.248/29). A 28-bit or smaller prefix length is recommended, especially if you are planning to use ExpressRoute.
A best practice for determining the address space of the Azure gateway subnet is the following:
Decide on the size of the gateway subnet.
In the variable bits in the address space of the VNet, set the bits used for the gateway subnet to 0 and set the remaining bits to 1.
Convert to decimal and express as an address space with the prefix length set to the size of the gateway subnet.
With this method, the address space for the gateway subnet is always at the farthest end of the VNet address space.
Here is an example of defining the address prefix for the gateway subnet: The address space of the VNet is 10.119.0.0/16. The organization will initially use a site-to-site VPN connection, but will eventually get ExpressRoute. Table 2 shows the steps and results of determining the gateway subnet address prefix in network prefix notation (also known as CIDR).
Virtual machine-hosting subnets are where you place Azure virtual machines, which you can do according to typical on-premises guidelines, such as a common role or tier of an application or for subnet isolation.
Azure uses the first 3 addresses on each subnet. Therefore, the number of possible addresses on an Azure subnet is 2n - 5, where n is the number of host bits. Table 3 shows the range of virtual machines required, the number of hosts bits needed, and the corresponding subnet size.
Azure assigns virtual machines the addresses of DNS servers by DHCP. DNS servers can be:
Supplied by Azure: Provides local name registration and local and Internet name resolution
Provided by you: Provides local or intranet name registration and either intranet or Internet name resolution
In some cases, you want to distribute incoming traffic to a set of servers that have the same role. Azure IaaS has a built-in facility to do this for Internet-facing and internal traffic loads.
Azure Internet-facing load balancing randomly distributes unsolicited incoming traffic from the Internet to the members of a load-balanced set.
Azure internal load balancing randomly distributes unsolicited incoming traffic from other Azure VMs or from intranet computers to the members of a load-balanced set.
If you need to forward traffic to virtual appliances in your VNet, you may need to add one or more user-defined routes to a subnet.
There are multiple ways to provide Internet access to the virtual machines on a VNet, which includes access from your organization network through your proxy server or other edge device.
Method | Deployment model |
---|---|
1. Endpoints and ACLs configured on cloud services | Classic |
2. Network security groups | Resource Manager and classic |
3. Internet-facing load balancer with inbound NAT rules | Resource Manager |
4. Network security appliances in the Azure Marketplace (not shown) | Resource Manager and classic |
Additional security is provided by:
Remote Desktop and SSH connections, which are authenticated and encrypted.
Remote PowerShell sessions, which are authenticated and encrypted.
IPsec transport mode, which you can use for end-to-end encryption.
Azure DDOS protection, which helps prevent external and internal attacks
VNets can be connected to each other using topologies similar to those used for connecting the sites of an organization.
You can connect to VMs in a VNet in the following ways:
Administration of VNet VMs from your on-premises network or the Internet
IT workload access from your on-premises network
Extension of your network through additional VNets
Security for connections is provided by the following:
P2S uses the Secure Socket Tunneling Protocol (SSTP)
S2S and VNet-to-VNet VPN connections use IPsec tunnel mode with AES256
ExpressRoute is a private WAN connection
Your on-premises VPN device or router acts as:
An IPsec peer, terminating the S2S VPN connection from the Azure gateway.
The BPG peer and termination point for the private peering ExpressRoute connection.
Routing to VNets from on-premises consists of the following:
A route for the VNet address space that points toward your VPN device.
A route for the VNet address space on your VPN device that points across the S2S VPN or ExpressRoute connection
ou can create an ExpressRoute connection with private peering between your on-premises network and the Microsoft cloud in three different ways:
Co-located at a cloud exchange
Point-to-point Ethernet connections
Any-to-any (IP VPN) networks
For the routing to on-premises or other VNets from a VNet, Azure forwards traffic across an Azure gateway that matches the Local Network address space assigned to the gateway.
You can define the Local Network address space in the following ways:
Option 1: The list of prefixes for the address space currently needed or in use (updates might be needed when you add new subnets).
Option 2: Your entire on-premises address space (updates only needed when you add new address space).
Because the Azure gateway does not allow summarized routes, you must define the Local Network address space for option 2 so that it does not include the VNet address space
Here is an example of defining the prefixes for the Local Network address space around the address space "hole" created by the VNet:
To ensure that on-premises computers can resolve the names of Azure-based servers and Azure-based servers can resolve the names of on-premises computers, configure:
The DNS servers in your VNet to forward to on-premises DNS servers
DNS replication of the appropriate zones between DNS servers on-premises and in the VNet
The default system route for Azure subnets points to the Internet. To ensure that all traffic from virtual machines travels across the cross-premises connection, create a routing table with the default route that uses the Azure gateway as its next-hop address. You then associate the route table with the subnet. This is known as forced tunneling.