Forum Widgets
Latest Discussions
Azure Load Balancer and security headers
Hi, If I need to set Access-Control-Allow-Origin (something else than *) in the server. Does anybody have experiences if that is header is traveling through the Azure Load Balancer? Some documentations are saying that LB needs to be able to support these headers. I'm asking this in this way, as this is kind of preparing for the future, while not be able to test that yet. Neither I was not able to find any Azure documentation for this.
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.
DNS Private Resolver forwarding ruleset resiliency
We are using DNS Private Resolver for all our tenant's Azure DNS resolution. We have a DNS forwarding ruleset set up that forwards all DNS requests for "ourcompany.com." to 10.0.0.100 (primary onprem DNS server IP) and 10.0.0.200 (secondary onprem DNS server IP). This is all working fine. We have just been looking at the resiliency of this setup. If both IPs were unreachable for five minutes, would the DNS private resolver return any cached DNS results for *.ourcompany.com or would the queries simply fail? If only the primary IP (10.0.0.100) were unavailable, presumably DNS queries would still succeed due to use of the secondary IP, but would there be any noticeable increase in the time to respond to DNS queries as a result?
BGP Routing from and to VPN Gateway
Hello All, I am setting up a lab concerning vWAN connection to onprem via SDWAN and I have some issues getting the routing to work properly. I have a hub which symbolizes the on-premises hub with a VPN gateway (gw-onprem) and a VM (on-prem-hubvm) deployed. Attached to the onprem-hub is a) on-prem spoke with a VM (on-prem VM). b) two vnets that symbolize the sdwan. Both of which have a VPN gateway as well as one VM each deployed (gw-sd-1/2) The SDWan Gateways are connected via s2s to two different vWAN hubs in two different locations. The vWAN has a third Hub which is not directly connected to on-prem What I am trying to lab is what direction the traffic is tacking from the vWAN Hubs to the last on-premise VM. The traffic currently goes all the way through the s2s vpn connection, but it gets dropped afterwards. I am struggling to set-up the routing from the sd-gw's to the on-premises machine. The routing needs to work through BGP The goal of the Lab is to see which path to on-premises is preferred if the hub preference is AS Path (shortest BGP Path). BGP is enabled on all VPN Gateways The SD GWs are peered to the onprem Hub GW but no vnet peering. The on-premises Vnets are peered. Somehow the VPN Gateways are not learning the routes to on-premises. I tried pointing the way with UDRs but somehow it also isnt working I've tried setting up UDRs so that the traffic would be the following vWAN Hub -> sd GW > sd VM > GW-onprem (> on-prem-hubvm) > on-prem VM
Azure Firewall has no capacity to maintain source IP on outbound traffic?
Hello all, My use case: To have multiple static public IP addresses attached to Azure Firewall with SNAT rules configured so that the public IP isn't just randomly selected. We have multiple services that have whitelisting configured for specific public load balancer IPs and now we are trying to move them behind Azure Firewall. Since there is whitelisting on the destination, the public IP being randomly selected won't work. My resources: One instance of premium SKU Azure Firewall. Hub and spoke architecture. Route tables being used to force traffic through Firewall (routed to private IP of firewall) The research I have conducted: I have tried absolutely everything I can think of before coming to this forum and from what I can tell the 4 ways of outbound connectivity provided by Azure are: Default outbound connectivity. Against best practice to do this and won't work since its routing through a virtual appliance (firewall) Associate a NAT gateway to a subnet. This won't work since we have only one instance of Azure Firewall and the requirement for multiple public IPs to be used. Assign a public IP to a virtual machine. Not applicable, sitting in backend pool of a load balancer, single public IP to be used for multiple member servers. Using the frontend IP address(es) of a load balancer for outbound via outbound rules. Needs to go through the firewall, impossible unless we can somehow integrate the firewall between the load balancer and the backend pool? Expanding more on the load balancer scenario, I ran across this documentation in Microsoft Learn. This looks great to tackle the asymmetric routing issue, however, we are only interested in maintaining the source IP for outbound traffic, this would again just use the firewalls public IP for outbound traffic and again randomly select it. Consensus: It seems bizarre to me that Azure has no capacity for static SNAT configuration like most firewalls do. I would have thought a large amount of use cases would require this function. Am I missing something? Is there another workaround? Or is Azure just behind the 8ball with networking. Thanks heaps in advance for any help :) Much Appreciated, usernameone101App Connectivity issue
I have come across an issue being reported by one of the user stating that he is unable to connect to an application on port 5672 hosted behind azure internal load balancer. on my observation from Azure portal post login i see that Azure front end load balancer is marking the front end port as unresponsive/down for service 5672, while the back end port 2009 on azure internal load balancer is seen up on the back end pool virtual F5 .port mapping done properly on azure Error as seen on Azure is “TCP probe out, unhealthy backend instances or unhealthy app listening on port” However when I check on the Virtual F5 the backend server is responding on port 5672 normally, the health checks look ok, thereby the vip is marked as up. is this abnormal behaviour on the application side against 5672 service or something more to check on the azure side which is resulting to TCP probe out error.. pls suggest
IP-based redirection
Hello! I am running a Linux VM on Azure (IaaS) which is providing an SFTP service to the Internet. Sadly, many customers are connecting to this service via public IP address (as opposed to FQDN). I am migrating this service back to on-premises, through a firewall on a different public IP address. Linux VM has public IP 1.1.1.1 right on its NIC. Firewall's IP is 2.2.2.2. I want to redirect traffic to the on-premises firewall. Is there an Azure service/resource that can take inbound connections to 1.1.1.1, then NAT the destination IP to 2.2.2.2 and then also NAT the source IP to 1.1.1.1 or another public IP (like 3.3.3.3) on that service/resource? Thanks!
Azure Firewall Application Rules - "MSSQL" not available in Rule Collection Groups
Hi, Working on a IaC project for Azure Firewall. Have created Azure Firewall, Azure Firewall Policy and working on implementing rules using Rule Collection Groups. In the Portal, Application Groups support protocol type "http", "https" and "mssql". However, when provisioning this using the Rule Collection Group module, that is just not an option at all, only HTTP and HTTPS is available: However, in the Azure Firewall module, you have all three: I am more fan of doing this modular, so would like to avoid having to do the rules directly in the Azure Firewall module. Is there any particular reason for why Mssql is not available directly from "Rule Collection Group" module? Is there any Github issue page for Azure networking where I could report this? Thanks!Azure Network Routing to VPN and Expressroute
I am trying to get Network Routing in azure between the below set up. Vnet A - VPN (peered to workload) Vnet B - Workload Vnet C - ExpressRoute (peered to workload) Each network will be peered to the Workload to allow traffic between them but the VPN Gateway option to allow the peering to be used will be switched off as Azure doesn't support 2 or more peerings with the VNET Gateway feature switched on natively. I have looked for other means using User Defined Routes. I wanted to route any traffic as an example on 10.0.0.0/8 over the Expressroute and then any traffic on 10.222.20./24 over the VPN. Now in theory I thought this would work but in practice it doesn't, the route gets confused where to go and ends up erroring out. My research has led me to believe that its just not achievable without having an Azure WAN in the middle to control all the traffic? Has anyone had any experience with this or used a different method? Thank you in advance.
