The post Bicep: Azure Virtual WAN Playground appeared first on Apostolidis Cloud Corner.
]]>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:
You can choose to:
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.
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
The post Bicep: Azure Virtual WAN Playground appeared first on Apostolidis Cloud Corner.
]]>The post NSG Flow Logs review in Log Analytics appeared first on Apostolidis Cloud Corner.
]]>While text-based logs offer vital insights, Microsoft Azure takes it a step further by providing Log Analytics, a powerful tool that allows administrators to visualize NSG flow logs. By leveraging Log Analytics, administrators can gain a comprehensive understanding of network traffic patterns and potential security risks. However, it’s worth noting that Log Analytics has a slight drawback—the polling of logs from the Storage Account occurs every 10 minutes. Therefore, for instant log review, direct access to the storage account is necessary to obtain the most up-to-date information.
Enabling NSG Flow Logs in Log Analytics involves a two-step process. Firstly, you need to create a flow log and traffic analytics workspace. Detailed instructions for setting up flow logs for a single NSG can be found in this Microsoft documentation: https://learn.microsoft.com/en-us/azure/network-watcher/nsg-flow-logging#create-a-flow-log-and-traffic-analytics-workspace. Additionally, if you want to deploy NSG flow logs across multiple NSGs using Azure Policy, refer to this guide: Manage NSG flow logs using Azure Policy – Azure Network Watcher | Microsoft Learn. These resources offer step-by-step instructions to configure NSG Flow Logs according to your specific requirements.
Once NSG Flow Logs are enabled and actively collecting data, accessing and analyzing the logs becomes crucial. To view the logs, navigate to the Log Analytics Workspace, where you’ll find a built-in query named “IPv4 NSF Flow Log Search.” This pre-configured query streamlines the log analysis process, allowing you to efficiently retrieve and examine relevant log data. By utilizing this query, you can filter and manipulate the logs to extract valuable insights on network traffic patterns, potential security incidents, or any other specific information of interest.
Let’s see some custom queries to narrow down the results based on the needs.
Search all traffic from a Public IP against a Network Security Group:
AzureNetworkAnalytics_CL | extend NSGRuleAction=split(NSGRules_s,'|',3)[0] | extend NSGRuleName=tostring(split(NSGRules_s,'|',1)[0]) | extend NSGName=tostring(split(NSGList_s,'/',2)[0]) | where NSGName == "labdc-nsg" | where SrcPublicIPs_s contains "167.2XX.XX.XX" | summarize count() by SourcePubIPs=SrcPublicIPs_s, SourceIP=SrcIP_s, DestinationIP=DestIP_s, DestinationPort=DestPort_d, TimeGenerated, NSGName, NSGRuleName, SourceSubnet=Subnet1_s, DestinationSubnet=Subnet2_s
Results:
Search for internal traffic between two VMs:
AzureNetworkAnalytics_CL | extend NSGRuleAction=split(NSGRules_s,'|',3)[0] | extend NSGRuleName=tostring(split(NSGRules_s,'|',1)[0]) | extend NSGName=tostring(split(NSGList_s,'/',2)[0]) | where NSGName == "labdc-nsg" | where DestIP_s == "192.168.200.4" and SrcIP_s == "192.168.200.5" | summarize count() by SourcePubIPs=SrcPublicIPs_s, SourceIP=SrcIP_s, DestinationIP=DestIP_s, DestinationPort=DestPort_d, TimeGenerated, NSGName, NSGRuleName, SourceSubnet=Subnet1_s, DestinationSubnet=Subnet2_s
Results:
Search for traffic from internal IP to a public destination:
AzureNetworkAnalytics_CL | extend NSGRuleAction=split(NSGRules_s,'|',3)[0] | extend NSGRuleName=tostring(split(NSGRules_s,'|',1)[0]) | extend NSGName=tostring(split(NSGList_s,'/',2)[0]) | where NSGName == "labdc-nsg" | where SrcIP_s == "192.168.200.5" | summarize count() by SourcePubIPs=SrcPublicIPs_s, SourceIP=SrcIP_s, DestPublicIPs=DestPublicIPs_s, DestinationPort=DestPort_d, TimeGenerated, NSGName, NSGRuleName, SourceSubnet=Subnet1_s, DestinationSubnet=Subnet2_s
Results:
In summary, Azure Network Security Groups serve as powerful access control devices for regulating network traffic within an Azure virtual network. The inclusion of NSG flow logs and Log Analytics enhances administrators’ visibility and understanding of network activity. By following the necessary steps to enable NSG Flow Logs and leveraging the Log Analytics Workspace, you can effectively monitor and analyze network traffic data, thereby improving the security and performance of your Azure resources.
The post NSG Flow Logs review in Log Analytics appeared first on Apostolidis Cloud Corner.
]]>The post Azure Global Distribution Solutions appeared first on Apostolidis Cloud Corner.
]]>Microsoft Azure Front Door is a content delivery network (CDN) service that offers application layer load balancing features. On the other hand, Azure cross-region Load Balancer serves as a global network layer load balancer. Lastly, Azure Traffic Manager operates as a domain name service (DNS)-based solution for distributing traffic.
Azure cross-region Load Balancer is designed to efficiently handle layer-4 traffic with minimal latency. It offers geo-proximity routing, ensuring that traffic from various locations is directed to the closest regional deployment. Moreover, the load balancer automatically handles failover, redirecting traffic to healthy regional deployments if any of them become unhealthy. Users benefit from a static globally anycast IP address, eliminating concerns about IP address changes.
Azure Front Door is a highly effective solution for achieving accelerated and resilient web application performance on a global scale, ensuring optimal delivery of both static and dynamic content. Here are the key features and benefits:
Use Azure Front Door to create powerful web applications by leveraging the integration of multiple Azure services while ensuring performance, scalability, and security.
Azure Traffic Manager is a DNS-based traffic load balancer. It offers the flexibility to incorporate on-premises servers into the backend, enabling support for scenarios such as burst-to-cloud, failover-to-cloud, and migrate-to-cloud. It provides automatic failover and multi-region support, ensuring that traffic is served with minimal latency. DNS name resolution is fast, and results are cached to enhance performance. The speed of the initial DNS lookup depends on the client’s DNS servers for name resolution, typically completing within approximately 50 ms. The lookup results are cached according to the DNS time-to-live (TTL), with the default TTL for Traffic Manager set at 300 seconds (around five minutes). Additionally, Azure Traffic Manager offers geographic routing capabilities, allowing users to direct traffic to the appropriate backend instance based on the geographical location, thus assisting with geofencing requirements.
Azure Front Door | Azure cross-region Load Balancer | Azure Traffic Manager | |
Traffic type | HTTP/HTTPS | TCP/UDP | DNS |
Routing policies | Latency, priority, round robin, weighted round robin, path-based, advanced http rules engine | Geo-proximity and Hash Based | Geographical, latency, weighted, priority, subnet, multi-value |
Supported environments. | Azure, non-Azure cloud, on-premises | Azure | Azure, non-Azure cloud, on-premises |
Backend Types | Azure Application Gateway, Azure Load balancer, Azure Traffic Manger | Azure Load Balancer | Azure Application Gateway, Azure Load balancer, Azure Traffic Manager, Azure Front Door, Azure Cross Region Load Balancer |
Session affinity | Yes | Yes | No |
Site acceleration | Yes | No | No |
Caching | Yes | No | No |
Global Static IP | No | Yes | No |
Security | DDOS, Web Application Firewall, Private Link | Network Security Group | Azure Resource Logs, Azure Policies |
SLA | 99.99% | 99.99% | 99.99% |
Pricing | Pricing | Pricing | Pricing |
References:
The post Azure Global Distribution Solutions appeared first on Apostolidis Cloud Corner.
]]>The post Azure Policy to enable network policies for private endpoints appeared first on Apostolidis Cloud Corner.
]]>By default, network policies are disabled for a subnet in a virtual network and you need to enable it manually, from the Azure Portal after the VNET creation, or you need to specify it in your script if you are deploying with PowerShell, Cli, Bicep or any other IaC.
To ensure that Network security policies are enabled, and force enable it, we can use an Azure Policy. The below Azure Policy checks if the Network security policies are enabled, and if not it automatically enables it. The result of this policy is:
The Policy:
{ "mode": "All", "policyRule": { "if": { "field": "Microsoft.Network/virtualNetworks/subnets[*].privateEndpointNetworkPolicies", "notEquals": "Enabled" }, "then": { "effect": "modify", "details": { "roleDefinitionIds": [ "/providers/Microsoft.Authorization/roleDefinitions/4d97b98b-1d4f-4787-a291-c67834d212e7" ], "operations": [ { "operation": "addOrReplace", "field": "Microsoft.Network/virtualNetworks/subnets[*].privateEndpointNetworkPolicies", "value": "Enabled" } ] } } }, "parameters": {} }
To add the Policy to your Azure environment:
The Policy is in Audit only mode, in case you just need to audit if there are any subnets that don’t have privateEndpointNetworkPolicies enabled.
{ "mode": "All", "policyRule": { "if": { "allOf": [ { "field": "type", "equals": "Microsoft.Network/virtualNetworks/subnets" }, { "field": "Microsoft.Network/virtualNetworks/subnets[*].privateEndpointNetworkPolicies", "notEquals": "Enabled" } ] }, "then": { "effect": "audit" } }, "parameters": {} }
You can get the Policy Json files at my Github repo: https://github.com/proximagr/automation#policy-audit—enable-network-policy-for-private-endpoints-blog-post
The post Azure Policy to enable network policies for private endpoints appeared first on Apostolidis Cloud Corner.
]]>The post Azure Databricks With existing DNS, Azure Networks & on-premises network appeared first on Apostolidis Cloud Corner.
]]>You can find a PowerShell script at my Automation repository to automatically create all required routes and a template csv with all IPs for West & East Europe Regions.
Link to GitHub: automation/DatabricksRoutes at master · proximagr/automation (github.com)
Script:
$location = '' $routeTableRGName = '' $routeTable = '' $vnetRGName = '' $vnetName = '' $subnetName = '' $subnetAddressPfx = '' $routeTableName = '' $dataBricksRouteName = '' $routesPath = 'C:\...\routes.csv' $i = 1 # Create or Get Azure Route Table if ($routeTable = $null) { $routeTable = New-AzRouteTable -ResourceGroupName $routeTableRGName -Location $location -Name $routeTableName } else { $routeTable = Get-AzRouteTable -ResourceGroupName $routeTableRGName -Name $routeTableName } # Create Routes $routes = import-csv $routesPath foreach ($route in $routes) { Add-AzRouteConfig -Name "$($dataBricksRouteName)-$($i)" -AddressPrefix $route.route -RouteTable $routeTable -NextHopType internet $i = $i+1 } # Commit the changes Set-AzRouteTable -RouteTable $routeTable # Associate the Route Table with Subnets $vnet = Get-AzVirtualNetwork -ResourceGroupName $vnetRGName -Name $vnetName Set-AzVirtualNetworkSubnetConfig -VirtualNetwork $vnet -Name $subnetName -AddressPrefix $subnetAddressPfx -RouteTable $routeTable # Commit the changes Set-AzVirtualNetwork -VirtualNetwork $vnet
Template CSV with West & North Europe Regions IPs:
route 52.232.19.246/32 20.38.84.81/32 23.97.201.41/32 40.127.147.196/32 20.73.215.48/28 51.138.96.158/32 52.138.224.7/32 52.138.224.6/32 52.239.137.164/32 20.60.246.65/32 20.150.26.228/32 20.150.104.100/32 52.239.138.100/32 52.236.40.36/32 20.150.104.4/32 20.150.76.228/32 52.239.141.36/32 13.69.64.0/32 52.169.18.8/32 104.40.169.187/32 13.69.105.208/32 20.60.223.36/32 20.60.222.107/32 20.150.122.36/32 52.239.242.196/32 20.60.26.196/32 20.60.223.68/32 20.60.222.129/32 20.150.74.100/32 20.150.122.68/32 52.239.141.68/32 20.60.196.33/32 20.60.250.196/32 20.38.108.228/32
The post Azure Databricks With existing DNS, Azure Networks & on-premises network appeared first on Apostolidis Cloud Corner.
]]>The post Global Azure Greece 2022 appeared first on Apostolidis Cloud Corner.
]]>As an Organizer, Volunteer, and Speaker, I felt the best of all. The people that gathered to see the presentations, to network in person with peers and friends, the rush for the check-in, the management of the lunch area, and the excitement to speak in front of so many people. Everything was perfect for a community-driven event.
The post Global Azure Greece 2022 appeared first on Apostolidis Cloud Corner.
]]>The post Network Policy for Private Endpoints appeared first on Apostolidis Cloud Corner.
]]>When using the portal to create a private endpoint, the PrivateEndpointNetworkPolicies setting is automatically disabled as part of the create process
Currently, this feature is in Public Preview, limited to some Azure Regions.
REF: Manage network policies for private endpoints – Azure Private Link | Microsoft Docs
The post Network Policy for Private Endpoints appeared first on Apostolidis Cloud Corner.
]]>The post Azure Firewall Policy Rules to CSV 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.
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 }
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:
The post Azure Firewall Policy Rules to CSV appeared first on Apostolidis Cloud Corner.
]]>The post Azure Routing Experiences | Scenario 3 appeared first on Apostolidis Cloud Corner.
]]>At the previews posts, we covered the basics of routing traffic from/to on-premises, inspecting all traffic through Azure Firewall, and configuring the DNS for accessing the Private Endpoints. In this scenario, I am experimenting with connectivity between on-premises, the Hub & Spoke networks and a second level peered network (a network that is peered behind the Spoke network).
Recap of Scenario 1 & 2: We have a Hub network, two Spoke networks and an IPSec VPN connection with my on-premises network. We established routing all traffic through the Azure Firewall for inspection & configured DNS for accessing the Private Endpoint from on-premises & all Azure VNets.
In the third scenario, I am adding a new Spoke VNet, the “Azure 2” peered with my hub, and a third VNet, the “Azure 3” that is only peered with the “Azure 2” VNet. To enable connectivity between the “Azure 3” VNet and the rest of the networks, including the on-premises, we need a router at the “Azure 2” VNet. This can be an NVA or Azure Firewall. In my case, I added an Azure Firewall. The Azure Firewall of “Azure 2” VNet has the private IP: 192.168.200.64.
Let’s describe a packet’s journey. The On-premises Server X (10.0.2.10) makes sends a packet to 10.100.0.4. 1st hop the packet goes to the default gateway, reaching the on-premises VPN device, in our case the RRAS. The RRAS has a custom route for 10.100.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 10.100.0.0/16 and forwards the packet to the HUB Azure Firewall, 192.168.2.4. The HUB Azure Firewall has a custom route for 10.100.0.0/16 and forwards the packet to the “Azure 2” Azure Firewall, 192.168.200.68. The “Azure 2” Azure Firewall does not have a custom route, but it has a route for 10.100.0.0/16 that is automatically populated by the VNet peering. The Azure FIrewall knows to forward the packet through the VNet peering and reaches the destination.
You can find more commends and tests in the below diagram with the whole solution.
Diagram: (Click here to download a high-resolution SVG image)
References:
Azure Routing Experiences | Scenario 1 – Apostolidis Cloud Corner
Azure Routing Experiences | Scenario 2 – Apostolidis Cloud Corner
Use Azure Firewall to inspect traffic destined to a private endpoint – Azure Private Link | Microsoft Docs
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
The post Azure Routing Experiences | Scenario 3 appeared first on Apostolidis Cloud Corner.
]]>The post Azure Routing Experiences | Scenario 2 appeared first on Apostolidis Cloud Corner.
]]>This scenario shares the same topology as Azure Routing Experiences | Scenario 1 with some changes in order to route all traffic through the Azure Firewall. This will allow us to have full control & inspection of all traffic from/to on-premises and all Azure traffic from/to all VNets. To achieve this we need some Route Table configuration.
At first, to control the traffic from the on-premises network, we need to add a Route Table to the GatewaySubnet to route all traffic through the Azure Firewall. 192.168.0.0/24, 192.168.4.0/24 & 192.168.5.0/24 Next Hop: 192.168.2.4. Now if we try to access the Storage Account, we will realize that we are still going directly from the VPN Gateway to the Storage account, (10.0.1.4 -> AzureGW -> 192.168.4.4). This happens because the Private Endpoint services populate a /32 route to the VNet and all peered VNets. The effective routes of the VPN Gateway now have our custom 192.168.4.0/24 -> 192.168.2.4 route but they also have the 192.168.4.4/32 -> Virtual Network route that is created by the Private Endpoint Service. Since it is a more specific route, it takes priority. The only way to bypass this in a hybrid scenario like this is to create a /32 route “192.168.4.4/32 Next Hop 192.168.2.4”. You can check more scenarios here. Now the GatewaySubnet Route Table is:
192.168.0.0/24 Next Hop 192.168.2.4
192.168.4.0/24 Next Hop 192.168.2.4
192.168.5.0/24 Next Hop 192.168.2.4
192.168.4.4/32 Next Hop 192.168.2.4
After this Route Table is applied to the GatewaySubnet, we can inspect the traffic coming from on-premises through the Azure Firewall logs. The /32 Route for the Private Endpoint must be applied to all Route Tables that are on VNets that are directly peered with the Private Endpoint VNet. I also added the /32 route to the VMSubnet. The Spoke2 subnet does NOT need to have the /32 route, since it is not directly peered with the Private Endpoint VNet. To access the Private Endpoint we added the /32 route to all Hub VNets, the GatewaySubnet, and the VMs subnet. The /32 route is not needed only services at the Spoke2 subnet, that is not directly peered with the Spoke1 subnet that has the Private Endpoint. And this is why the /32 route is created together with the Private Endpoint and it is populated to all peered subnets.
About the DNS configuration, as discussed in Scenario 1, to access Azure PaaS services, like the Storage, the Azure SQL, the Web App, we need to use the URI, since they don’t listen to the IP. Since we have Azure Firewall at the configuration, and I have enabled the Azure Firewall DNS Proxy feature to use it as a Conditional Forwarder for the on-premises DNS, we can also use it for the Azure estate. I changed the DNS of the Spoke2 VNet to the Azure Firewall, 192.168.2.4 to be able to resolve the Storage account’s Private IP. Linking all Private DNS zones to Azure Firewall’s VNet, usually the Hub VNet, we can use Azure Firewall as our DNS server to all VNets.
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.4.4/32 and sends the packet to the Azure Firewall, 192.168.2.4. The Azure Firewall does not have a custom route, but it has a route that is automatically populated by the VNet peering with address 192.168.4.4/32. The Azure Firewall knows to forward the packet through the VNet peering and reaches the destination.
You can find more commends and test at the diagram below:
References:
Azure Routing Experiences | Scenario 1 – Apostolidis Cloud Corner
Use Azure Firewall to inspect traffic destined to a private endpoint – Azure Private Link | Microsoft Docs
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
The post Azure Routing Experiences | Scenario 2 appeared first on Apostolidis Cloud Corner.
]]>