In this post we will go over creating VNETs and subnets using PowerShell, we will also be create a script to use a CSV to deploy multiple VNETs / subnets.
Azure PowerShell is a command-line tool that allows you to manage and deploy Azure resources using the PowerShell scripting language.
Azure VNETs provide a secure and isolated network environment within Azure. Subnets allow you to divide a VNET into smaller, logical segments to control network traffic and provide network segregation.
To deploy Azure VNET and subnets using Azure PowerShell, we first either need to create a resource group or use a pre existing one.
We can create a resource group using Az PowerShell
First connect to Azure PowerShell using
Once connected if there is multiple subscription make sure to select the correct one before creating the resource group or any other resource.
Next we will create the resource group this requires a name and a location.
New-AzResourceGroup -Name 'resource group name' -Location northeurope
Next we can create a VNET and subnet will be using splatting to specifying the parameters.
Azure NSG flow logs are a feature of Azure Network Security Group (NSG) that allows administrators to track and monitor network traffic flowing through their Azure virtual network.
The flow logs provide detailed information on the source and destination of the traffic, as well as the protocol and port being used. This information can be used to identify trends and patterns in network usage, as well as to detect and troubleshoot potential security threats.
Azure NSG flow logs provide a valuable tool for administrators to maintain visibility and control over their Azure network environment.
To set the NSG flow logs to be sent to Log workspace we can use Traffic Analytics.
In this post we will be going through enabling NSG Flow Logs, enabling Traffic Analytics and reviewing the logs for allowed and denied traffic using Azure Log Analytics Workspace.
There will be a cost for using the Azure Storage, workspace and Traffic Analytics so confirm these before proceeding as the more data sent the more it will cost.
When creating a new deployment in Azure it is good security practice to restrict access between subnets to the required ports only. This can sometimes be a bit difficulty if the application communication is not fully documented.
This is where NSG Flow can be used as we can use this to review the traffic between the subnets going over the NSG’s. There are some prerequisite for this
Storage account in the same region as the NSG
Log Analytic workspace
Network Watcher (this should be created automatically once a vNet is created)
Network Security group
VM running in two network and have an NSG assigned
Once all the above are ready we can start to enabled the logging. NSG flow can be either enabled from NSG directly or through Network Watcher. We will be doing this in Network Watcher.
First step is to go to Network Watcher > NSG Flow
Select the required Subscription, the required NSG’s, storage account and retention (0 on retention means the logs are kept forever) since this is a test environment I will only keep the logs for 5 days.
On configuration select version 2 and enabled traffic analytics. On traffic analytics set the process interval to either 1 hour or 10 mins, select the subscription and workspace.
Apply tags if in use, then review and create.
The deployment should only take a minute or so and then the NSG flow should show as succeeded.
Once enabled it can take little bit for data to start showing. We can check that the container has been create on the storage account.
Open the storage account and go to Containers there should be a new insight-logs container.
If we navigate down the folder structure there will be a JSON file that has all the NSG access requests, we could use the JSON file it self but it pretty difficult to read.
To check that data is going to the workspace, go to Log Analytics Workspace. Select the workspace we used earlier.
We will use the AzureNetworkAnalytics_CL table and flowlog to view the data. I used the below Learn article to help understand the table / fields and create the queries.
To allow communication between vNet’s in Azure we can set up peering connections. This is useful if there is a need to have different vNet’s for things like web app’s and backend database zones.
To configure peering we will require two different vNets both must be in the same Azure region.
Currently when I try to ping a VM that is running in a different vNet there is no communication.
Logon to Azure
Go to All services > Virtual networks
Once in Virtual networks select the network that will be configure for peering
Once the network blade is open go to peering > Add
Enter a Name, select the Subscription that the other vNet is in. Then Select the Virtual Network. Under configuration select Enabled and the last step tick Allow forwarded traffic
Below are some details on three options:
Allow forwarded traffic: This setting allows the peer’s forwarded traffic (traffic not originating from inside the peer virtual network) into your virtual network. Allow gateway transit: Allows the peer virtual network to use your virtual network gateway. The peer virtual network cannot already have a gateway configured, and must select ‘use remote gateway’ in its peering settings. Use remote gateway: You will need to Select this option if you wish to use your peer’s virtual network gateway. The peer virtual network must have a gateway configured, as well as ‘allow gateway transit’ enabled. Only one peering in this virtual network can have this enabled. You cannot use this setting if you already have a gateway configured in your virtual network.
Once all settings are confirmed click ok to create the peering
Two allow communication both ways, there will need to peering setup on the App network aswell.
Once both are enabled we can now see response to ping requests
To lock down communication between the networks we can add NSG’s to restricted what inbound and outbound traffic is allowed from the subnet’s.