Forum Widgets
Latest Discussions
Using Azure Bastion via through vWAN Virtual Hub
I have a feedback about Azure Bastion. I am using the ability to use Azure Bastion with multiple virtual networks via vNET Peering. I would like to extend this feature to use it via a Virtual WAN hub. However, the current Azure Bastion does not seem to detect peering through a virtual hub. I hope Azure Bastion to be able to connect to VM hosts on different virtual networks via a virtual hub.
AZ-700 Step by Step Guide for Azure Private DNS
This article is part of our AZ-700 series, offering a step-by-step guide on configuring Azure Private DNS, based on the tutorial available on YouTube. I highly recommend watching the video to gain a solid understanding of the concepts covered in this article. Through this guide, you'll gain hands-on experience in setting up and managing Azure Private DNS, enabling efficient DNS resolution, network segmentation, and seamless automation within Microsoft Azure. In today’s cloud environment, managing network resources and ensuring secure connectivity across virtual networks (vNets) can be complex, particularly when DNS management comes into play. This article provides a comprehensive, hands-on guide to setting up and configuring Azure Private DNS for efficient DNS resolution, network segmentation, and seamless automation in Microsoft Azure. Follow along as we explore the essential elements, from linking vNets and subnets to DNS automation. Why Azure Private DNS? Azure Private DNS allows you to manage and resolve DNS names within a virtual network without exposing them to the public internet. It simplifies domain name resolution, enhances security, and enables automation for dynamic environments. Key benefits of using Azure Private DNS: Dynamic DNS Management: Automatically updates DNS records for new or deleted resources, eliminating stale or "dangling" DNS entries. Domain Delegation: Allows centralized DNS management by delegating your corporate domain to Azure Private DNS. Enhanced Security: DNS records are automatically removed when resources are deleted, ensuring up-to-date and secure network configuration. Quick Recap: Azure Networking Fundamentals Before diving into Azure Private DNS, let’s revisit some foundational concepts from our previous discussions: vNet (Virtual Network): Similar to a traditional VLAN but without broadcast support, a vNet enables secure and scalable resource management. Subnet: Subdivision within a vNet, allowing more granular control over resource segmentation. Azure allows you to set up a single vNet with multiple subnets, maximizing network organization and security without the broadcast overhead typical in traditional networks. Step 1: Understanding Azure Private DNS Azure Private DNS enables the automatic registration of DNS names for resources within your vNet. For example, when you create a virtual machine (VM) in a vNet linked to a private DNS zone, the VM’s name and IP address automatically register within the zone. This streamlines DNS management, especially for dynamic environments where resources are created and deleted frequently. Key Features Automatic DNS Registration: Automatically updates the DNS zone with new or removed resources. Domain Delegation: You can delegate your corporate domain to the private DNS zone, managing DNS records centrally within Azure. Support for All DNS Record Types: Azure DNS supports a full range of DNS records, including A, AAAA, CNAME, and MX records. Step 2: Setting Up the Private DNS Zone 1. Create a Private DNS Zone In the Azure Portal, navigate to Private DNS Zones and create a new zone. Define a name for the DNS zone, such as yourdomain.private. Deploy the DNS zone and navigate to the resource. 2. Link vNets for Automatic DNS Registration Within the Private DNS Zone resource, select Virtual Network Links to connect vNets to the DNS zone. For each vNet (e.g., Core Services, West Europe, Asia), specify the vNet link and enable Auto Registration. This enables seamless DNS name resolution across linked vNets and allows automatic DNS record updates when resources are created or deleted. Step 3: Verifying DNS Resolution and Connectivity Verify DNS Records in the Private DNS Zone: Go to DNS Management under the Private DNS zone and check that the A records for the VMs appear. Connect to VMs via DNS: Use Remote Desktop to access one VM, then attempt to connect to the other VM by its DNS name (rather than IP address). This confirms that the Private DNS setup allows for name-based connectivity. If issues arise (e.g., timeouts), ensure that firewall settings permit connectivity between the VMs. Step 4: DNS Zone Peering Across Regions With Azure Private DNS, you can link vNets across different regions, allowing resources in different geographic locations to resolve names and connect seamlessly. Link vNets Across Regions: Connect the vNets in regions like West Europe, East US, and Asia to the Private DNS zone. Verify Regional Connectivity: From a VM in one region (e.g., Asia), test connectivity to a VM in another region (e.g., East US) using DNS names. Azure Private DNS allows DNS name resolution across regions, ensuring consistent and reliable network connectivity. Summary Setting up Azure Private DNS is a powerful way to automate and centralize DNS management within a virtual network environment. This guide provides a practical framework for deploying Private DNS zones, linking vNets, and verifying connectivity. By configuring Azure Private DNS, organizations can streamline DNS management, secure network configurations, and enhance connectivity across geographically dispersed resources. Next Steps In future tutorials, we’ll explore VNet peering for advanced network configurations, allowing secure communication between isolated virtual networks. Be sure to subscribe and stay tuned for more Azure networking tips and tricks! Let’s enhance your Azure network management with practical, hands-on solutions.Deploy Dynamic Routing (BGP) between Azure VPN and Third-Party Firewall (Palo Alto)
Overview This blog explains how to deploy dynamic routing (BGP) between Azure VPN and a third-party firewall. You can refer to this topology and deployment guide in scenarios where you need VPN connectivity between an on-premises third-party VPN device and Azure VPN, or any cloud environment. What is BGP? Border Gateway Protocol (BGP) is a standardized exterior gateway protocol used to exchange routing information across the internet and between different autonomous systems (AS). It is the protocol that makes the internet work by enabling data routing between different networks. Here are some key points about BGP: Routing Between Autonomous Systems: BGP is used for routing between large networks that are under different administrative control, known as autonomous systems (AS). Each AS is assigned a unique number. Path Vector Protocol: BGP is a path vector protocol, meaning it maintains the path information that gets updated dynamically as routes are added or removed. This helps in making routing decisions based on path attributes. Scalability: BGP is designed to handle a large number of routes, making it highly scalable for use on the internet. Policy-Based Routing: BGP allows network administrators to set policies that can influence routing decisions. For example, administrators can prefer certain routes over others based on specific criteria such as path length or AS path. Peering: BGP peers are routers that establish a connection to exchange routing information. Peering can be either internal (within the same AS) or external (between different AS). Route Advertisement: BGP advertises routes along with various attributes such as AS path, next hop, and network prefix. This helps in making informed decisions on the best route to take. Convergence: BGP can take some time to converge, meaning to stabilize its routing tables after a network change. However, it is designed to be very stable once converged. Use in Azure: In Azure, BGP is used to facilitate dynamic routing in scenarios like connecting Azure VNets to on-premises networks via VPN gateways. This dynamic routing allows for more resilient and flexible network designs. Switching from static routing to BGP for your Azure VPN gateway will enable dynamic routing, allowing the Azure network and your on-premises network to exchange routing information automatically, leading to potentially better failover and redundancy. Why BGP? BGP is the standard routing protocol commonly used in the Internet to exchange routing and reachability information between two or more networks. When used in the context of Azure Virtual Networks, BGP enables the Azure VPN gateways and your on-premises VPN devices, called BGP peers or neighbors, to exchange "routes" that will inform both gateways on the availability and reachability for those prefixes to go through the gateways or routers involved. BGP can also enable transit routing among multiple networks by propagating routes a BGP gateway learns from one BGP peer to all other BGP peers. Diagram Pre-Requisite Firewall Network: Firewall with three interfaces (Public, Private, Management). Here, the LAB has configured with VM-series Palo Alto firewall. Azure VPN Network: Test VM, Gateway Subnet Test Network Connected to Firewall Network: Azure VM with UDR pointing to Firewall's Internal Interface. The test network should be peered with firewall network. Configuration Part 1: Configure Azure VPN with BGP enabled Create Virtual Network Gateway from marketplace Provide Name, Gateway type (VPN), VPN SKU, VNet (with dedicated Gateway Subnet), Public IP Enable BGP and provide AS number Create Note: Azure will auto provision a local BGP peer with an IP address from Gateway Subnet. After deployment the configuration will look similar to below. Make a note of Public IP and BGP Peer IP generated, we need this while configuring VPN at remote end. Create Local Network Gateway Local Network Gateway represents the firewall VPN network Configuration where you should provide remote configuration parameters. Provide Name, Remote peer Public IP In the Address space specify remote BGP peer IP (/32) (Router ID in case of Palo Alto). Please note that if you are configuring static route instead of dynamic you should advertise entire remote network ranges which you want to communicate through VPN. Here BGP making this process much simpler. In Advanced tab enable BGP and provide remote ASN Number and BGP peer IP create Create Connections with default crypto profile Once the VPN Gateway and Local Network Gateway has provisioned you can build connection which represents IPsec and IKE configurations. Go to VPN GW and under Settings, Add Connection Provide Name, VPN Gateway, Local Network Gateway, Pre-Shared Key Enable BGP If Required, Modify IPsec and IKE Crypto setting, else leave it as default Create Completed the Azure end configuration, now we can move to firewall side. Part 2: Configure Palo Alto Firewall VPN with BGP enabled Create IKE Gateway with default IKE Crypto profile Provide IKE Version, Local VPN Interface, Peer IP, Pre-shared key Create IPSec Tunnel with default IPsec Crypto profile Create Tunnel Interface Create IPsec Tunnel: Provide tunnel Interface, IPsec Crypto profile, IKE Gateway Since we are configuring route-based VPN, tunnel interface is very necessary to route traffic which needed to be encrypted. By this configuration your tunnel should be UP Now finish the remaining BGP Configurations Configure a Loopback interface to represent BGP virtual router, we have provided 10.0.17.5 IP for the interface, which is a free IP from public subnet. Configure virtual router Redistribution Profile Configure Redistribution Profile as below, this configuration ensures what kind of routers needed to be redistributed to BGP peer routers Enable BGP and configure local BGP and peer BGP parameters Provide Router ID, AS number Make sure to enable Install Route Option Configure EBGP Peer Group and Peer with Local BGP Peer IP, Remote (Azure)BGP Peer IP and Remote (Azure) BGP ASN Number. Also Specify Redistribution profile, make sure to enable Allow Redistribute Default Route, if you need to propagate default route to BGP peer router Create Static route for Azure BGP peer, 10.0.1.254/32 Commit changes Test Results Now we can test the connectivity, we have already configured necessary NAT and default route in Firewall. You can see the propagated route in both azure VPN gateway and Palo Alto firewall. FW NAT Name Src Zone Dst Zone Destination Interface Destination Address Service NAT Action nattovm1 any Untrust any untrust_inteface_pub_ip 3389 DNAT to VM1 IP nattovm2 any Untrust any untrust_interface_pub_ip 3000 DNAT to VM2 IP natto internet any Untrust ethernet1/1 default 0.0.0.0/0 SNAT to Eth1/1 Stattic Route configured: Azure VPN GW Connection Status and Propagated routes Azure Test VM1 (10.0.0.4) Effective routes Palo Alto BGP Summary Palo Alto BGP connection status Palo Alto BGP Received Route Palo Alto BGP Propagated Route Final Forwarding table Ping and trace result from Test VM1 to test VM2 Conclusion: BGP simplifies the route advertisement process. There are many more configuration options that we can try in BGP to achieve smooth functioning of routing. BGP also enables automatic redundancy and high availability. Hence, it is always recommended to configure BGP when it comes to production-grade complex networking.
VPN Gateway - BGP AS PATH - Steer which VPN tunnel traffic will flow form Azure to OnPrem
Can anyone confirm whether in the topology that Microsoft calls "Active-active VPN gateways" we can steer which VPN tunnel is utilized using AS PATH? Or is it by definition active/active, meaning we can't avoid utilizing both tunnels simultaneously and probably we have to deal with asymetric routing? MS article about different topologies: https://learn.microsoft.com/en-us/azure/vpn-gateway/vpn-gateway-highlyavailable#activeactiveonprem My findings: Because the Azure gateway instances are in active-active configuration, the traffic from your Azure virtual network to your on-premises network will be routed through both tunnels simultaneously, even if your on-premises VPN device might favor one tunnel over the other. However, according to the Microsoft FAQ about BGP: Yes, Azure VPN gateway honors AS Path prepending to help make routing decisions when BGP is enabled. A shorter AS Path is preferred in BGP path selection.
Connecting Azure Databricks VMs to external VNet for Log Analytics ingestion
Hello, We run an ADB cluster using cluster pools. I'm looking for a way connect the ADB cluster pool VMs which reside on the automatically generated Resource Group databricks-rg-<xyz> to another Resource Group and VNet where Log Analytics resource reside. The communication needs to be over private IPs since we block public ingestion in the Log Analytics workspace for security propose. The VMs will report OMS metrics for performance proposes. See this link for more details: https://github.com/Azure/AzureDatabricksBestPractices/blob/master/toc.md#Appendix-A) See following diagram: I found this link: https://learn.microsoft.com/en-us/azure/databricks/administration-guide/cloud-configurations/azure/private-link but I'm not sure it's for this propose. When trying to create the private-link on the ADB resource I have the following options to pick from: "databricks_ui_api" and "browser_authentication", which both seems not relevant for my need. Appreciate your help on this matter. Thank you!Is it possible to send public load balancer traffic to Internal Load Balancer?
Hi, I have 2 VM's with web application installed, these are clustered with NLB (Because of application limitation/support). Created Azure Internal Load balancer with Frontend IP assigned to NLB cluster. I can access web application internally(Locally / when connected to VPN) using internal load balancer. Now I want to access that web application over the internet (publically). I created public load balancer and added inetnal load balancer IP in backend pool but I can't access web application over the internet. I have NSG associated with Subnet where I added Any , Any Rule. Is it possible to send traffic from Public load balancer to Internal Load Balancer? Question apart from this scenario: What should be NSG rule to send traffic from Public Load balancer to VM's in backend pool? Any, Any rule works for this but I want to be more restrictive/specific for NSG rule.
Virtual Network in Azure. Please Explain
Hi All, What does it mean when we say Azure uses Virtual Networking? How does software defined networking work? End of the scene, we interact with cloud through physical networking only. How is the boundary maintained in the cloud? Please provide some resources to understand the layout of virtual networking in cloudAzure Service Endpoint
In terms of security, one of the best practices for reducing the attack surface of a service is to avoid exposing it to the Internet. This obviously also applies to PaaS services deployed on Azure, which is why Azure offers different solutions to achieve this. Today we are going to see one of them, with the Service Endpoint which is a functionality allowing to consume services via the internal network of Azure, also called Azure backbone . Before getting to the heart of the matter, it is important to remember that in the majority of cases, when you deploy a new PaaS service on Azure, it is by default exposed on the Internet. This is voluntary on Microsoft's part, so that this new service can be quickly accessible for other services, whether they are hosted on Azure, on an On-Premise environment, or with another Cloud provider. In order to explain how Service Endpoint works , we will deploy the following components on Azure: Storage Account – SA (PaaS Service which will be taken as an example) Virtual Machine – VM Hard drive – Disk Network interface – NIC Security group – NSG Virtual network – VNET Subnet Public IP address Put into practice For our use case, we want our VM that we have previously deployed to be able to consume data stored in our SA. We'll see what the possibilities are afford, with and without the Service Endpoint feature . PAAS SERVICE EXPOSED ON THE INTERNET For our first example, our Storage Account will have no limitation, and will therefore be exposed on the Internet. (Obviously this is not to be reproduced for obvious security reasons, but it helps to better understand the Service Endpoint mechanism ). Here is a small diagram that explains how our SA will be consumed by our VM, and potentially by other services or external users: We can see that when our VM goes out on the Internet and then comes to consume our SA via its public DNS, in our case https://demo736.blob.core.windows.net/ We have a first lesson. When a VM wishes to consume a service deployed on Azure, by default, the network flow goes out on the Internet before coming to consume the service on its public endpoint. Knowing that in our use case, only our VM must consume our SA, we have no interest in exposing our SA on the Internet. We are therefore going to add restrictions at the level of the SA Firewall. ACTIVATION OF THE FIREWALL ON THE PAAS SERVICE As we saw in our previous example, the SA is exposed to the internet, allowing all traffic from the internet. In order to limit access only to our VM, in the Firewall configuration of the SA, we will only authorize the public IP address of our VM: Have a look at our diagram again: Now we see that traffic from the internet is blocked and only our VM's public IP address is allowed to connect to the SA. In terms of security, it's better, but we can go even further with to the Service Endpoint. ENABLING THE SERVICE ENDPOINT Setting up the Endpoint Service is very easy to do. It is done in two steps: The first, by selecting the service that we want to consume, at the level of the subnet in which our VM is deployed. In our example, as we want to consume our SA, the service name will be Microsoft.Storage . After selection, we see the status which changes to New . The second, by adding the subnet in which our VM is deployed at the Firewall level of our SA. We also took the opportunity to remove the public IP address of our VM which is no longer useful. A new look at our diagram: We now see that the VM's network flow no longer goes through the Internet, but directly via Azure's internal network (Azure backbone). And of course, Internet traffic is still blocked. But how does it work in practice? In fact, when you activate the Service Endpoint at the level of a subnet, the resources that are deployed within it are assigned new routes that will forward the network flow to the Azure Service Endpoint. For example, here are the routes associated with our NIC, and therefore with our VM: At the time of writing this post, here is the list of Service Endpoints available in Azure: 1 . In general availability Azure Storage (Microsoft.Storage) Azure SQL Database (Microsoft.Sql) Azure Synapse Analytics (Microsoft.Sql) Azure Database Server for PostgreSQL (Microsoft.Sql) Azure Database Server for MySQL (Microsoft.Sql) Azure Database for MariaDB (Microsoft.Sql) Azure Cosmos DB (Microsoft.AzureCosmosDB) Azure Key Vault (Microsoft.KeyVault) Azure Service Bus (Microsoft.ServiceBus) Azure Event Hubs (Microsoft.EventHub) Azure Data Lake Store Gen 1 (Microsoft.AzureActiveDirectory) Azure App Service (Microsoft.Web) Azure Cognitive Services (Microsoft.CognitiveServices) 2 . In public preview Azure Container Registry (Microsoft.ContainerRegistry) This information is obviously available on the official Microsoft documentation . CONCLUSION To summarize, Service Endpoint is an excellent solution for not exposing its PaaS services on the Internet, but some point to one of these flaws. Indeed, using the Service Endpoint feature, the traffic is not directed directly to a service (our SA in our example), but to the Storage category of Azure. Well, we will see that Microsoft offers another feature, namely Private Link, which allows you to directly consume a PaaS service, by assigning it a private IP address directly within a VNET. This will be the subject of a future post!
