[Azure Doc-a-thon]edits to network powershell

ZarrVenkat · ZarrVenkat · commit 10e042324095 · 2025-07-10T12:37:06.000+05:30
diff --git a/articles/firewall-manager/secure-cloud-network-powershell.md b/articles/firewall-manager/secure-cloud-network-powershell.md
@@ -28,40 +28,39 @@ In this tutorial, you learn how to:
 
 - If you don't have an Azure subscription, create a [free account](https://azure.microsoft.com/free/?WT.mc_id=A261C142F) before you begin.
 
-- PowerShell 7
+- PowerShell 7 or higher
 
-   This tutorial requires that you run Azure PowerShell locally on PowerShell 7. To install PowerShell 7, see [Migrating from Windows PowerShell 5.1 to PowerShell 7](/powershell/scripting/install/migrating-from-windows-powershell-51-to-powershell-7).
+   This tutorial requires that you run Azure PowerShell locally on PowerShell 7 or higher. To install PowerShell 7, see [Migrating from Windows PowerShell 5.1 to PowerShell 7](/powershell/scripting/install/migrating-from-windows-powershell-51-to-powershell-7).
 
 - "Az.Network" module version must be 4.17.0 or higher.
 
 ## Sign in to Azure
 
-```azurepowershell
+```azurepowershell-interactive
 Connect-AzAccount
 Select-AzSubscription -Subscription "<sub name>"
 ```
 
 ## Initial Virtual WAN deployment
+To begin, you need to set variables and create the resource group, the virtual WAN instance, and the virtual hub:
 
-As a first step, you need to set some variables and create the resource group, the virtual WAN instance, and the virtual hub:
-
-```azurepowershell
+```azurepowershell-interactive
 # Variable definition
 $RG = "vwan-rg"
 $Location = "westeurope"
 $VwanName = "vwan"
 $HubName =  "hub1"
 $FirewallTier = "Standard" # or "Premium"
 
-# Create Resource Group, Virtual WAN and Virtual Hub
+# Create Resource Group, Virtual WAN and Virtual Hub using the New-AzVirtualWan and New-AzVirtualHub cmdlets
 New-AzResourceGroup -Name $RG -Location $Location
 $Vwan = New-AzVirtualWan -Name $VwanName -ResourceGroupName $RG -Location $Location -AllowVnetToVnetTraffic -AllowBranchToBranchTraffic -VirtualWANType "Standard"
 $Hub = New-AzVirtualHub -Name $HubName -ResourceGroupName $RG -VirtualWan $Vwan -Location $Location -AddressPrefix "192.168.1.0/24" -Sku "Standard"
 ```
 
-Create two virtual networks and connect them to the hub as spokes:
+- Create two virtual networks and connect them to the hub as spokes using the `New-AzVirtualHubVnetConnection` cmdlet. The virtual networks are created with the address prefixes `10.1.1.0/24` and `10.1.2.0/24`.
 
-```azurepowershell
+```azurepowershell-interactive
 # Create Virtual Network
 $Spoke1 = New-AzVirtualNetwork -Name "spoke1" -ResourceGroupName $RG -Location $Location -AddressPrefix "10.1.1.0/24"
 $Spoke2 = New-AzVirtualNetwork -Name "spoke2" -ResourceGroupName $RG -Location $Location -AddressPrefix "10.1.2.0/24"
@@ -70,9 +69,11 @@ $Spoke1Connection = New-AzVirtualHubVnetConnection -ResourceGroupName $RG -Paren
 $Spoke2Connection = New-AzVirtualHubVnetConnection -ResourceGroupName $RG -ParentResourceName  $HubName -Name "spoke2" -RemoteVirtualNetwork $Spoke2 -EnableInternetSecurityFlag $True
 ```
 
-At this point, you have a fully functional Virtual WAN providing any-to-any connectivity. To enhance it with security, you need to deploy an Azure Firewall to each Virtual Hub. Firewall Policies can be used to efficiently manage the virtual WAN Azure Firewall instance. So a firewall policy is created as well in this example:
+At this stage, your Virtual WAN is fully operational and provides any-to-any connectivity. To secure this environment, deploy an Azure Firewall in each Virtual Hub. You can centrally manage these firewalls using Firewall Policies. 
 
-```azurepowershell
+In this example, you'll also create a firewall policy to manage the Azure Firewall instance in the Virtual WAN hub using the `New-AzFirewallPolicy` cmdlet. The Azure Firewall will be deployed in the hub using the `New-AzFirewall` cmdlet.
+
+```azurepowershell-interactive    
 # New Firewall Policy
 $FWPolicy = New-AzFirewallPolicy -Name "VwanFwPolicy" -ResourceGroupName $RG -Location $Location
 # New Firewall Public IP
@@ -88,9 +89,9 @@ $AzFW = New-AzFirewall -Name "azfw1" -ResourceGroupName $RG -Location $Location
 > [!NOTE]
 > The following Firewall creation command does **not** use availability zones. If you want to use this feature, an additional parameter **-Zone** is required. An example is provided in the upgrade section at the end of this article.
 
-Enabling logging from the Azure Firewall to Azure Monitor is optional, but in this example you use the Firewall logs to prove that traffic is traversing the firewall:
+Enabling logging from Azure Firewall to Azure Monitor is optional. In this example, you use firewall logs to verify that traffic is passing through the firewall. First, create a Log Analytics workspace to store the logs. Then, use the `Set-AzDiagnosticSetting` cmdlet to configure diagnostic settings and send the logs to the workspace.
 
-```azurepowershell
+```azurepowershell-interactive
 # Optionally, enable logging of Azure Firewall to Azure Monitor
 $LogWSName = "vwan-" + (Get-Random -Maximum 99999) + "-" + $RG
 $LogWS = New-AzOperationalInsightsWorkspace -Location $Location -Name $LogWSName -Sku Standard -ResourceGroupName $RG
@@ -109,9 +110,11 @@ Now you have an Azure Firewall in the hub, but you still need to modify routing
 
 
 
-Start with the first step, to configure your virtual network connections to propagate to the `None` Route Table:
+Begin by configuring your virtual network connections to propagate to the `None` Route Table. This step ensures that the virtual networks do not learn each other's address prefixes, preventing direct communication between them. As a result, all inter-virtual network traffic must pass through the Azure Firewall.
 
-```azurepowershell
+To do this, use the `Get-AzVhubRouteTable` cmdlet to retrieve the `None` Route Table, and then update each virtual network connection's routing configuration with the `Update-AzVirtualHubVnetConnection` cmdlet.
+
+```azurepowershell-interactive
 # Configure Virtual Network connections in hub to propagate to None
 $VnetRoutingConfig = $Spoke1Connection.RoutingConfiguration    # We take $Spoke1Connection as baseline for the future vnet config, all vnets will have an identical config
 $NoneRT = Get-AzVhubRouteTable -ResourceGroupName $RG -HubName $HubName -Name "noneRouteTable"
@@ -125,9 +128,9 @@ $Spoke1Connection = Update-AzVirtualHubVnetConnection -ResourceGroupName $RG -Pa
 $Spoke2Connection = Update-AzVirtualHubVnetConnection -ResourceGroupName $RG -ParentResourceName  $HubName -Name "spoke2" -RoutingConfiguration $VnetRoutingConfig
 ```
 
-Now you can continue with the second step, to add the static routes to the `Default` route table. In this example, you apply the default configuration that Azure Firewall Manager would generate when securing connectivity in a Virtual WAN, but you can change the list of prefixes in the static route to fit your specific requirements:
+Next, proceed to the second step: adding static routes to the `Default` route table. The following example uses the default configuration that Azure Firewall Manager applies when securing connectivity in a Virtual WAN. You can customize the list of prefixes in the static route as needed by using the `New-AzVHubRoute` cmdlet. In this example, all traffic is routed through the Azure Firewall, which is the recommended default.
 
-```azurepowershell
+```azurepowershell-interactive
 # Create static routes in default Route table
 $AzFWId = $(Get-AzVirtualHub -ResourceGroupName $RG -name  $HubName).AzureFirewall.Id
 $AzFWRoute = New-AzVHubRoute -Name "all_traffic" -Destination @("0.0.0.0/0", "10.0.0.0/8", "172.16.0.0/12", "192.168.0.0/16") -DestinationType "CIDR" -NextHop $AzFWId -NextHopType "ResourceId"
@@ -151,11 +154,9 @@ $AzFWId = $(Get-AzVirtualHub -ResourceGroupName <thname> -name  $HubName).AzureF
 $policy1 = New-AzRoutingPolicy -Name "PrivateTraffic" -Destination @("PrivateTraffic") -NextHop $firewall.Id
 $policy2 = New-AzRoutingPolicy -Name "PublicTraffic" -Destination @("Internet") -NextHop $firewall.Id
 New-AzRoutingIntent -ResourceGroupName "<rgname>" -VirtualHubName "<hubname>" -Name "hubRoutingIntent" -RoutingPolicy @($policy1, $policy2)
-```
-
-If you are using non-RFC1918 prefixes in your Virtual WAN such as  40.0.0.0/24 in your Virtual Network or on-premises, add an additional route in the defaultRouteTable after routing intent configuration completes. Make sure you name this route as **private_traffic**. If the route is named otherwise, the desired configuration will apply but it will not be reflected in Azure Portal.
+If your Virtual WAN uses non-RFC1918 address prefixes (for example, `40.0.0.0/24` in a virtual network or on-premises), you should add an extra route to the `defaultRouteTable` after completing the routing intent configuration. Name this route **private_traffic**. If you use a different name, the route will work as expected, but the configuration will not be reflected in the Azure Portal.
 
-```azurepowershell
+```azurepowershell-interactive
 # Get the defaultRouteTable
 $defaultRouteTable = Get-AzVHubRouteTable -ResourceGroupName routingIntent-Demo -HubName wus_hub1 -Name defaultRouteTable
 
@@ -176,9 +177,9 @@ Update-AzVHubRouteTable -ResourceGroupName <rgname> -ParentResourceName <hubname
  
 ## Test connectivity
 
-Now you have a fully operational secure hub. To test connectivity, you need one virtual machine in each spoke virtual network connected to the hub:
+Now that your secure hub is fully operational, you can test connectivity by deploying a virtual machine in each spoke virtual network connected to the hub:
 
-```azurepowershell
+```azurepowershell-interactive
 # Create VMs in spokes for testing
 $VMLocalAdminUser = "lab-user"
 $VMLocalAdminSecurePassword = ConvertTo-SecureString -AsPlainText -Force
@@ -206,9 +207,9 @@ $Spoke2VMPrivateIP = $NIC2.IpConfigurations[0].PrivateIpAddress
 $Spoke2VMPIP = $(Get-AzPublicIpAddress -ResourceGroupName $RG -Name "spoke2-pip")
 ```
 
-The default configuration in the firewall policy is to drop everything. So you need to configure some rules. Start with DNAT rules, so that the test virtual machines are accessible over the Firewall's public IP address:
+By default, the firewall policy blocks all traffic. To allow access to your test virtual machines, you must configure DNAT (Destination Network Address Translation) rules. These rules will enable you to connect to the VMs through the Azure Firewall's public IP address:
 
-```azurepowershell
+```azurepowershell-interactive
 # Adding DNAT rules for virtual machines in the spokes
 $AzFWPublicAddress = $AzFW.HubIPAddresses.PublicIPs.Addresses[0].Address
 $NATRuleSpoke1 = New-AzFirewallPolicyNatRule -Name "Spoke1SSH" -Protocol "TCP" `
@@ -222,9 +223,9 @@ $NATCollection = New-AzFirewallPolicyNatRuleCollection -Name "SSH" -Priority 100
 $NATGroup = New-AzFirewallPolicyRuleCollectionGroup -Name "NAT" -Priority 100 -RuleCollection $NATCollection -FirewallPolicyObject $FWPolicy
 ```
 
-Now you can configure some example rules. Define a network rule that allows SSH traffic, plus an application rule that allows Internet access to the Fully Qualified Domain Name `ifconfig.co`. This URL returns the source IP address it sees in the HTTP request:
+Next, configure example rules for your firewall policy. First, create a network rule to allow SSH traffic between the virtual networks. Then, add an application rule to permit Internet access only to the Fully Qualified Domain Name (FQDN) `ifconfig.co`, which returns the source IP address seen in the HTTP request:
 
-```azurepowershell
+```azurepowershell-interactive
 # Add Network Rule
 $SSHRule = New-AzFirewallPolicyNetworkRule -Name PermitSSH -Protocol TCP `
         -SourceAddress "10.0.0.0/8" -DestinationAddress "10.0.0.0/8" -DestinationPort 22
@@ -236,9 +237,9 @@ $AppCollection = New-AzFirewallPolicyFilterRuleCollection -Name "TargetURLs" -Pr
 $NetGroup = New-AzFirewallPolicyRuleCollectionGroup -Name "TargetURLs" -Priority 300 -RuleCollection $AppCollection -FirewallPolicyObject $FWPolicy
 ```
 
-Before actually sending any traffic, you can inspect the effective routes of the virtual machines. They should contain the prefixes learned from the Virtual WAN (`0.0.0.0/0` plus RFC1918), but not the prefix of the other spoke:
+Before sending any traffic, check the effective routes for each virtual machine. The route tables should show the prefixes learned from the Virtual WAN (`0.0.0.0/0` and RFC1918 ranges), but should not include the address prefix of the other spoke virtual network.
 
-```azurepowershell
+```azurepowershell-interactive
 # Check effective routes in the VM NIC in spoke 1
 # Note that 10.1.2.0/24 (the prefix for spoke2) should not appear
 Get-AzEffectiveRouteTable -ResourceGroupName $RG -NetworkInterfaceName $NIC1.Name | ft
@@ -247,30 +248,35 @@ Get-AzEffectiveRouteTable -ResourceGroupName $RG -NetworkInterfaceName $NIC1.Nam
 Get-AzEffectiveRouteTable -ResourceGroupName $RG -NetworkInterfaceName $NIC2.Name | ft
 ```
 
-Now generate traffic from one Virtual Machine to the other, and verify that it's dropped in the Azure Firewall. In the following SSH commands you need to accept the virtual machines fingerprints, and provide the password that you defined when you created the virtual machines. In this example, you're going to send five ICMP echo request packets from the virtual machine in spoke1 to spoke2, plus a TCP connection attempt on port 22 using the Linux utility `nc` (with the `-vz` flags it just sends a connection request and shows the result). You should see the ping failing, and the TCP connection attempt on port 22 succeeding, since it's allowed by the network rule you configured previously:
+Generate traffic from one virtual machine to the other and verify that it is filtered by Azure Firewall. Use SSH to connect to the virtual machines—accept the SSH fingerprint and enter the password you set during VM creation. In this example, you will:
 
-```azurepowershell
+- Send five ICMP echo requests (pings) from the VM in spoke1 to the VM in spoke2.
+- Attempt a TCP connection on port 22 using the `nc` (netcat) utility with the `-vz` flags, which checks connectivity without sending data.
+
+You should observe that the ping requests fail (blocked by the firewall), while the TCP connection on port 22 succeeds, as allowed by the previously configured network rule.
+
+```azurepowershell-interactive
 # Connect to one VM and ping the other. It should not work, because the firewall should drop the traffic, since no rule for ICMP is configured
 ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "ping $Spoke2VMPrivateIP -c 5"
 # Connect to one VM and send a TCP request on port 22 to the other. It should work, because the firewall is configured to allow SSH traffic (port 22)
 ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "nc -vz $Spoke2VMPrivateIP 22"
 ```
 
-You can also verify Internet traffic. HTTP requests via the utility `curl` to the FQDN you allowed in the firewall policy (`ifconfig.co`) should work, but HTTP requests to any other destination should fail (in this example you test with `bing.com`):
+You can also test Internet access through the firewall. HTTP requests using the `curl` utility to the allowed FQDN (`ifconfig.co`) should succeed, while requests to other destinations (such as `bing.com`) should be blocked by the firewall policy:
 
-```azurepowershell
+```azurepowershell-interactive
 # This HTTP request should succeed, since it is allowed in an app rule in the AzFW, and return the public IP of the FW
 ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "curl -s4 ifconfig.co"
 # This HTTP request should fail, since the FQDN bing.com is not in any app rule in the firewall policy
 ssh $AzFWPublicAddress -p 10001 -l $VMLocalAdminUser "curl -s4 bing.com"
 ```
 
-The easiest way to verify the packets are dropped by the firewall is to check the logs. Since you configured the Azure Firewall to send logs to Azure Monitor, you can use the Kusto Query Language to retrieve the relevant logs from Azure Monitor:
+To confirm that the firewall is dropping packets as expected, review the logs sent to Azure Monitor. Since Azure Firewall is configured to send diagnostic logs to Azure Monitor, you can use Kusto Query Language (KQL) to query and analyze the relevant log entries:
 
 > [!NOTE]
 > It can take around 1 minute for the logs to appear to be sent to Azure Monitor
 
-```azurepowershell
+```azurepowershell-interactive
 # Getting Azure Firewall network rule Logs
 $LogWS = Get-AzOperationalInsightsWorkspace -ResourceGroupName $RG
 $LogQuery = 'AzureDiagnostics
@@ -314,9 +320,7 @@ TimeGenerated            Protocol    SourceIP       SourcePort TargetIP      Tar
 If you want to see the logs for the application rules (describing allowed and denied HTTP connections) or change the way that the logs are displayed, you can try with other KQL queries. You can find some examples in [Azure Monitor logs for Azure Firewall](../firewall/firewall-workbook.md).
 
 
-## Clean up resources
-
-To delete the test environment, you can remove the resource group with all contained objects:
+To clean up the test environment, delete the resource group and all associated resources by using the `Remove-AzResourceGroup` cmdlet. This will remove the Virtual WAN, Virtual Hub, Azure Firewall, and any other resources created during this tutorial.
 
 ```azurepowershell
 # Delete resource group and all contained resources
@@ -325,14 +329,12 @@ Remove-AzResourceGroup -Name $RG
 
 ## Deploy a new Azure Firewall with availability zones to an existing hub
 
-The previous procedure uses Azure PowerShell to create a **new** Azure Virtual WAN Hub, and then immediately converts it to a Secured Hub using Azure Firewall.
-A similar approach can be applied to an **existing** Azure Virtual WAN Hub. Firewall Manager can be also used for the conversion, but it isn't possible to deploy Azure Firewall across availability zones without a script-based approach.
-You can use the following code snippet to convert an existing Azure Virtual WAN Hub to a Secured Hub, using an Azure Firewall deployed across all three availability zones.
+The previous steps showed how to use Azure PowerShell to create a **new** Azure Virtual WAN Hub and secure it with Azure Firewall. You can also secure an **existing** Azure Virtual WAN Hub using a similar script-based approach. While Firewall Manager can convert a hub to a Secured Hub, it does not support deploying Azure Firewall across availability zones through the portal. To deploy Azure Firewall in all three availability zones, use the following PowerShell script to convert your existing Virtual WAN Hub to a Secured Hub.
 
 > [!NOTE]
 > This procedure deploys a new Azure Firewall. You can't upgrade an existing Azure Firewall without availability zones to one with availability zones. You must first delete the existing Azure Firewall in the hub and create it again using this procedure.
 
-```azurepowershell
+```azurepowershell-interactive
 # Variable definition
 $RG = "vwan-rg"
 $Location = "westeurope"
@@ -364,7 +366,7 @@ After you run this script, availability zones should appear in the secured hub p
 
 :::image type="content" source="./media/secure-cloud-network/vwan-firewall-hub-az-correct7.png" alt-text="Screenshot of Secured virtual hub availability zones." lightbox="./media/secure-cloud-network/vwan-firewall-hub-az-correct7.png":::
 
-After the Azure Firewall is deployed, a configuration procedure must be completed as described in the previous *Deploy Azure Firewall and configure custom routing* section.
+After deploying Azure Firewall, you must complete the configuration steps outlined in the earlier **Deploy Azure Firewall and configure custom routing** section to ensure proper routing and security.
 
 ## Next steps
 
