Introduction
After explaining the basics in my previous blog, see link, now we will dive a bit deeper in Azure networking. After setting up the Virtual Network, Subnets, Network Security Groups and perhaps some Application Security Groups you might have to create some more complex stuff like Virtual Network Gateways, User Defined Routes (UDRs) en Private Endpoints.
Virtual Network Gateway
A virtual network gateway is a service within the Azure platform that gives you the ability to connect your on-premise environment to the virtual network in Azure. This service comes in many flavors, each with its own characteristics. For testing purposes, you can create a Basic virtual network gateway, but for production workloads a Basic one is not supported. While creating, u will be asked if you need a route or policy based VPN. The differences between route-based and policy-based are well explained by Microsoft. For further information, check the useful links section. While choosing the right flavor, you require information about the bandwidth that the VPN needs to handle. Based on that information, u decide on which Stock Keeping Unit (SKU) you require. At the moment, Azure offers 15 SKUs, all with different specifications depending on the needs of the customer. In my opinion, the VpnGw1 is the most common and most chosen. The VpnGw1 has no zone redundancy, if you need this you have to choose VpnGw1AZ, where that AZ stands for Availability Zone support.
User Defined Routes
Now that we have a connection from on-premise or a datacenter to Azure, you may want to regulate some traffic, this can be done by using User Defined Routes (UDRs). User defined routes are routes in Azure to override Azure’s default system routes, or to add additional routes to a subnet’s route table. Unlike Network Security Groups (NSGs) user defined routes can only be associated to a subnet. User defined routes are not always needed, they come in handy when you want to prevent the default Azure routing from taking over. For example, the default route between subnets are handled by Azure, but if you want to have a packet inspected before it routes to its destination, you need to direct the default route to a device that can inspect the packets. In one of my next blog, I will set up a device that can inspect packages and show that the packets are flowing through the device. If you want to check if you or a customer is using user defined routes, you have to go search for ‘route tables’ in the portal. In the ‘subnet associations’ part, you can see if there is a subnet associated to the user defined route. If there is a subnet associated and there are no routes set in the route table, the default Azure routes still work. So in order to use user defined routes, you need the following things:
- Create a route table through the portal or PowerShell;
- Assign a route table to a subnet;
- Define routes within the route table.
Private Endpoint
Another great feature of Azure is a private endpoint. A private endpoint is a network interface that uses a private IP address from your virtual network. Private endpoints can be used for multiple Azure services, like Azure Storage or Azure SQL. The normal way of communicating to these services are public facing, but when using private endpoints these services become part of your private network. For example, if you have an address space of 10.0.0.0/23 and a subnet of 10.0.1.0/24, the private endpoint of an Azure SQL server can become 10.0.1.10. By using this type of communication to Azure services, clients don’t need public access to internal services anymore. In many organizations, this is a requirement on a security level.
Conclusion
Azure offers many great networking features for connecting on-premises environments to Azure networks. Also, in order to keep control over the packets within your Azure network, there are also some great possibilities available.
Useful Links