Recently I created a Bicep code to create an Azure Virtual WAN with 2 Hubs, Azure Firewalls, and spoke VNETs & VMs, to use it for PoCs, Labs, and Tests. You can find it at my repo: https://github.com/proximagr/VWAN

The script deploys:

• One Log Analytics workspace
• Four VETS, two on each Azure Region.
• one VWAN with two VWAN HUBs, each on a different Azure Region.
• Two Azure Firewalls inside the VWAN Hubs, each on a different Azure Region. The Azure Firewalls have diagnostic settings sending all logs to a log analytics workspace.
• Two Azure Firewalls outside the VWAN Hubs, each on a different Azure Region. The Azure Firewalls have diagnostic settings sending all logs to a log analytics workspace.
• Four VMs, Ubuntu, one in each VNET

You can choose to:

• deploy VWAN or not
• deploy Azure Firewall inside the VWAN Hubs
• deploy VMs or not
• deploy Azure Firewall outside the VWAN Hubs or not
• how many Public IPs will be created and attached to the Azure Firewalls
• The Azure Firewall SKU between Basic and Standard

The script does NOT deploy the connections between the VWAN Hubs & the VNETS. Once the VWAN Hubs are ready, with Hub Status “Succeeded” and Router Status “Provisioned”, create the connections manually. This is because to create a connection the VWAN Hub Router Status must be “Provisioned” and currently, the is no way of getting this Status.

The VMs are for testing & troubleshooting. Ubuntu Linux, without Public IP. I usually use the Serial console.

Deployment Commands for Azure Cli:

create the Resource Group az group create –name ResourceGroupName –location PreferedLocation

deploy the bicep script and answer the questions interactively az deployment group create –resource-group ResourceGroupName –template-file main.bicep

deploy the bicep script with the required parameters and choose true false az deployment group create –resource-group ResourceGroupName –template-file main.bicep –parameters numberOfFirewallPublicIPAddresses=1 adminPassword=’#########’ adminUserName=’######’ deployVWAN=true addFirewallToVWAN=true deployFirewall=true deployFirewallBasic=true deployVMs=true

Deployment Diagram

VWAN Lab: https://github.com/proximagr/VWAN

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Bicep: Azure Virtual WAN Playground appeared first on Apostolidis Cloud Corner.

There is plenty of information and guides for Azure Firewall at the Microsoft Docs Azure Firewall documentation | Microsoft Docs. In this post, I want to share some PowerShell scripts that we created with my colleague Panagiotis Tsoukias. One script to Export all Firewall Policy rules, of all Policy Groups in a CSV file. Then edit the rules in Excel. And a second script to import the rules to the same or to a different Firewall Policy.

Export the Azure Firewall Policy Rules

The first script is to Export the Firewall Policy Rules of a Rule Collection, in a manageable CSV format. Edit the script, change the first three variables, and the path to export, and run it. Open the exported CSV with Microsoft Excel and you will have this result:

The first three columns are the Rule Collection’s Name, Priority & Action Type. We will need this info to create the Rule Collections and import the rules to the corresponding Rule Collection.

You can copy the script from the below box or download it from my GitHub link: Export Azure Firewall Policy Rules.ps1

#Provide Input. Firewall Policy Name, Firewall Policy Resource Group & Firewall Policy Rule Collection Group Name
$fpname = azfwpolicy
$fprg = azurehub
$fprcgname = DefaultNetworkRuleCollectionGroup

$fp = Get-AzFirewallPolicy -Name $fpname -ResourceGroupName $fprg
$rcg = Get-AzFirewallPolicyRuleCollectionGroup -Name $fprcgname -AzureFirewallPolicy $fp

$returnObj = @()
foreach ($rulecol in $rcg.Properties.RuleCollection) {

foreach ($rule in $rulecol.rules)
{
$properties = [ordered]@{
    RuleCollectionName = $rulecol.Name;
    RulePriority = $rulecol.Priority;
    ActionType = $rulecol.Action.Type;
    RUleConnectionType = $rulecol.RuleCollectionType;
    Name = $rule.Name;
    protocols = $rule.protocols -join ", ";
    SourceAddresses = $rule.SourceAddresses -join ", ";
    DestinationAddresses = $rule.DestinationAddresses -join ", ";
    SourceIPGroups = $rule.SourceIPGroups -join ", ";
    DestinationIPGroups = $rule.DestinationIPGroups -join ", ";
    DestinationPorts = $rule.DestinationPorts -join ", ";
    DestinationFQDNs = $rule.DestinationFQDNs -join ", ";
}
$obj = New-Object psobject -Property $properties
$returnObj += $obj
}

#change c:\temp to the path to export the CSV
$returnObj | Export-Csv c:\temp\rules.csv -NoTypeInformation
}

Import the Azure Firewall Policy Rules

After done editing the rules in Excel, we are ready to import them back to the Azure Policy or to a new Azure Policy. We need to export one CSV per Rule Collection. It will help us that the first column has the Rule Collection Name. Then run the import script. The script creates a Rule Collection, if it does not already exist, and adds the Rules in this specific Rule Collection.

You can copy the script from the below box or download it from my GitHub link: Import Azure Firewall Policy Rules.ps1

#Provide Input. Firewall Policy Name, Firewall Policy Resource Group & Firewall Policy Rule Collection Group Name
$fpname = azfwpolicy
$fprg = azurehub
$fprcgname = DefaultNetworkRuleCollectionGroup

$targetfp = Get-AzFirewallPolicy -Name $fpname -ResourceGroupName $fprg
$targetrcg = New-AzFirewallPolicyRuleCollectionGroup -Name $fprcgname -Priority 200 -FirewallPolicyObject $targetfp

$RulesfromCSV = @()
# Change the folder where the CSV is located
$readObj = import-csv C:\temp\rules.csv
foreach ($entry in $readObj)
{
    $properties = [ordered]@{
        RuleCollectionName = $entry.RuleCollectionName;
        RulePriority = $entry.RulePriority;
        ActionType = $entry.ActionType;
        Name = $entry.Name;
        protocols = $entry.protocols -split ", ";
        SourceAddresses = $entry.SourceAddresses -split ", ";
        DestinationAddresses = $entry.DestinationAddresses -split ", ";
        SourceIPGroups = $entry.SourceIPGroups -split ", ";
        DestinationIPGroups = $entry.DestinationIPGroups -split ", ";
        DestinationPorts = $entry.DestinationPorts -split ", ";
        DestinationFQDNs = $entry.DestinationFQDNs -split ", ";
    }
    $obj = New-Object psobject -Property $properties
    $RulesfromCSV += $obj
}

$RulesfromCSV
Clear-Variable rules
$rules = @()
foreach ($entry in $RulesfromCSV)
{
    $RuleParameter = @{
        Name = $entry.Name;
        Protocol = $entry.protocols
        sourceAddress = $entry.SourceAddresses
        DestinationAddress = $entry.DestinationAddresses
        DestinationPort = $entry.DestinationPorts
    }
    $rule = New-AzFirewallPolicyNetworkRule @RuleParameter
    $NetworkRuleCollection = @{
        Name = $entry.RuleCollectionName
        Priority = $entry.RulePriority
        ActionType = $entry.ActionType
        Rule       = $rules += $rule
    }
}

# Create a network rule collection
$NetworkRuleCategoryCollection = New-AzFirewallPolicyFilterRuleCollection @NetworkRuleCollection
# Deploy to created rule collection group
Set-AzFirewallPolicyRuleCollectionGroup -Name $targetrcg.Name -Priority 200 -RuleCollection $NetworkRuleCategoryCollection -FirewallPolicyObject $targetfp

Feel free to take, edit, use & comment on the scripts, you can find them at my repo:

Dark Mode

automation (this link opens in a new window) by proximagr (this link opens in a new window)

1 Subscriber 0 Watchers 0 Forks Check out this repository on GitHub.com (this link opens in a new window)

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure Firewall Policy Rules to CSV appeared first on Apostolidis Cloud Corner.

• Scenario 1: Hybrid connectivity with Azure VPN Gateway
• Scenario 2: Hybrid connectivity with Azure VPN Gateway & Traffic Inspection with Azure Firewall
• Scenario 3: Hybrid Connectivity with Azure VPN Gateway, second level peered networks & full traffic inspection with Azure Firewall

Scenario 1: Hybrid connectivity through Azure VPN gateway

At the start, I created the on-premises network, using a RRAS (Windows Server 2019 with Routing & Remote Access) to act as the router/VPN device and a Server with DNS service. The Azure estate has three VNets, in a hub & spoke topology. One HUB and two Spokes, connected with the HUB with VNet peering. There is no peering between the spokes. My Azure HUB network has three subnets, one has a VPN Gateway, the second has a VM, and the third has an Azure Firewall. In this first scenario, the Azure Firewall acts only as a DNS Proxy. It is not included in routing.

• On-premises network: 10.0.0.0/16
• HUB VNet Address Space: 192.168.0.0/22
• HUB GatewaySubnet: 192.168.1.0/24
• HUB VMSubnet: 192.168.0.0/24
• HUB Firewall Subnet: 192.168.2.0/24
• Spoke1 (storage account): 192.168.4.0/24
• Spoke2 (VM): 192.168.5.0/24

The first spoke has a Private Link to my storage account. The second spoke has a VM.. Azure VPN Gateway knows all routes of its VNet, the peered VNets & the routes propagated from the VPN connection. From on-premises, we can reach all resources using the VPN connection interface ( in RRAS I added a custom route “192.168.0.0 255.255.0.0 interface:AzureGW”)

From the VM of the HUB VNet (192.168.0.4), in order to be able to reach the on-premises network, we need a custom route, since the on-premises network is not populated to the VNet. I created a Route Table, with route “10.0.0.0/16 Next Hop: Virtual Network Gateway” attached to the VM Subnet.

To access the Private Endpoint of the Storage account we need some more resources & configuration. The storage account, as all PaaS services (like Web App & Azure SQL) responds only to URI and not to IP. Since we have connected a Private Endpoint to the Storage Account, the Public Access is blocked. So, in order to connect to the storage account, we need the aprostore.file.core.windows.net to translate to the private IP of the storage account, the 192.168.4.4. The proper way to achieve this is by using DNS.

First, we need to create a Private DNS zone and link it to the HUB VNET. For accessing blob storage we need a Private DNS zone with the name privatelink.blob.core.windows.net, for the file we need privatelink.file.core.windows.net. More services here. Then add the Storage Account Private Endpoint record to the Private DNS Zone. Now there is an A record azappsa with IP 192.168.4.4. Now, all Azure resources at the linked VNet, the HUB, are able to resolve the DNS records of the Private DNS Zone. We cannot resolve the records of the Azure Private DNS Zone from on-premises. To do so, we need a DNS server on Azure, to use as a conditional forwarder. This can be a Windows or Linux VM with DNS services or in my case, the Azure FIrewall with the DNS proxy enabled (I will use the whole functionality of the firewall to my next scenarios). I enabled the DNS Proxy on Azure, using default Azure DNS, and I added a conditional forwarding at the on-premises DNS “blob.core.windows.net -> 192.168.2.4” and “file.core.windows.net -> 192.168.2.44”. Now, I can successfully resolve the private IP of the storage account using its name, and be able to connect to it to both blob and to files with SMB access.

From the VM of the Spoke2 VNet (192.168.5.4), in order to be able to reach the on-premises network, we need a custom route, since the on-premises network is not populated to the VNet. I created a Route Table, with route “10.0.0.0/16 Next Hop: Virtual Network Gateway” attached to the VM Subnet. I added a second route “192.168.4.0/24 Next Hop: Virtual Network Gateway” & changed the VNet DNS to 192.168.2.4 (the Azure Firewall) to be able to access the Spoke1 VNet for storage access.

DNS & Routing example

DNS: The on-premises Server X, 10.0.2.10, makes a request to https://azappsa.blob.core.windows.net. At first, it asks the DNS to resolve the URL to an IP. The DNS has a conditional forwarder about blob.core.windows.net, and asks the Azure Firewall, 192.168.2.4. Azure Firewall has a linked Private DNS zone that has a host record for azappsa.blob.core.windows.net and it resolves to 192.168.4.4. This information routes back to Server X. Now Server X knows that the IP address of azappsa.blob.core.windows.net is 192.168.4.4.

Routing: To go to 192.168.4.4 first it asks its Default Gateway, in our case the RRAS. The RRAS has a custom route for 192.168.0.0/16 and forwards the packet to the VPN interface. The packet reaches the Azure VPN Gateway. The Azure VPN Gateway has a custom route for 192.168.0.0/24 BUT it also has a route for 192.168.4.4/32 that is automatically populated by the VNet peering. The /32 route is more specific than the /24 route, so the VPN Gateway forwards the packet directly to the Private Endpoint, bypassing the Azure Firewall. (At the Azure Routing Experiences | Scenario 2 we will see how we will force the traffic through the Azure Firewall.

Please find below the whole solution diagram, I tried to make it as analytic as possible, without messing with too many lines. Also, I have some notes and tests below.

References:
Azure Private Endpoint DNS configuration | Microsoft Docs
What is a virtual network link subresource of Azure DNS private zones | Microsoft Docs
Azure Firewall DNS Proxy details | Microsoft Docs
Create, change, or delete an Azure route table | Microsoft Docs

Pantelis Apostolidis

Pantelis Apostolidis is a Sr. Specialist, Azure at Microsoft and a former Microsoft Azure MVP. For the last 20 years, Pantelis has been involved to major cloud projects in Greece and abroad, helping companies to adopt and deploy cloud technologies, driving business value. He is entitled to a lot of Microsoft Expert Certifications, demonstrating his proven experience in delivering high quality solutions. He is an author, blogger and he is acting as a spokesperson for conferences, workshops and webinars. He is also an active member of several communities as a moderator in azureheads.gr and autoexec.gr. Follow him on Twitter @papostolidis.

www.cloudcorner.gr

The post Azure Routing Experiences | Scenario 1 appeared first on Apostolidis Cloud Corner.