Protect against React RSC CVE-2025-55182 with Azure Web Application Firewall (WAF)
Please subscribe to this blog as we will be updating the suggested rules as new attack permutations are found. On December 3, 2025, the React team disclosed a critical remote code execution (RCE) vulnerability in React Server Components (RSC), tracked as CVE-2025-55182. The vulnerability allows an unauthenticated attacker to send a specially crafted request to an RSC “Server Function” endpoint and potentially execute arbitrary code on the server. This vulnerability affects applications using React RSC in the following versions: 19.0.0 19.1.0 19.1.1 19.2.0 Patched versions are available, and all customers are strongly encouraged to update immediately. About CVE-2025-55182 According to the React security advisory, the issue stems from unsafe deserialization within React Server Components, where server function payloads were not adequately validated. When exploited, an attacker can execute arbitrary code on the server without authentication. The NVD entry classifies this vulnerability as Critical, with a CVSS score of 10.0, due to its ease of exploitation and the potential impact on server-side execution. All organizations using React Server Components — or frameworks that embed RSC capabilities such as Next.js, React Router (RSC mode), Waku, @parcel/rsc, @vitejs/plugin-rsc, or rwsdk — should consider themselves potentially exposed until the relevant patches are applied. Azure WAF Mitigation to CVE-2025-55182 The primary and most effective mitigation for this vulnerability is to upgrade any unpatched React versions to the latest security-patched releases. Add a custom WAF rule to mitigate CVE-2025-55182 If you wish to apply a CVE-specific mitigation, you can create custom WAF rules tailored to detect this exploit pattern. The custom rules action is configured to Block, so we recommend validating them in a test or staging environment before enforcing it in production. Custom rules definition for WAF on Application Gateway and Application Gateway for Containers: "customRules": [ { "name": "cve202555182", "priority": 1, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "PostArgs" } ], "operator": "Contains", "negationConditon": false, "matchValues": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "next-action" } ], "operator": "Any", "negationConditon": false, "matchValues": [], "transforms": [] } ], "skippedManagedRuleSets": [], "state": "Enabled" }, { "name": "cve202555182ver2", "priority": 100, "ruleType": "MatchRule", "action": "Block", "matchConditions": [ { "matchVariables": [ { "variableName": "PostArgs" } ], "operator": "Contains", "negationConditon": false, "matchValues": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "matchVariables": [ { "variableName": "RequestHeaders", "selector": "rsc-action-id" } ], "operator": "Any", "negationConditon": false, "matchValues": [], "transforms": [] } ], "skippedManagedRuleSets": [], "state": "Enabled" } ], If your Azure WAF is configured with an older ruleset version, such as CRS 2.2.9, CRS 3.0, or CRS 3.1, adding this custom rule may fail. In this case, we strongly recommend upgrading your WAF policy to the next-generation WAF engine by moving to a newer ruleset: either the latest DRS 2.1 (preferred) or the previous CRS 3.2. Once upgraded, you can apply the custom rule described above. If upgrading your ruleset version is not an option, you can instead use the following alternative rule: "CustomRules": [ { "Name": "cve202555182", "Priority": 1, "RuleType": "MatchRule", "MatchConditions": [ { "MatchVariables": [ { "VariableName": "PostArgs" } ], "Operator": "Contains", "MatchValues": [ "constructor", "__proto__", "prototype", "_response" ], "Transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "MatchVariables": [ { "VariableName": "RequestHeaders", "Selector": "next-action" } ], "Operator": "Regex", "MatchValues": [ "." ], "Transforms": [] } ], "Action": "Block" }, { "Name": "cve202555182ver2", "Priority": 2, "RuleType": "MatchRule", "MatchConditions": [ { "MatchVariables": [ { "VariableName": "PostArgs" } ], "Operator": "Contains", "MatchValues": [ "constructor", "__proto__", "prototype", "_response" ], "ATransforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] }, { "MatchVariables": [ { "VariableName": "RequestHeaders", "Selector": "rsc-action-id" } ], "Operator": "Regex", "MatchValues": [ "." ], "Transforms": [] } ], "Action": "Block" } ] Custom rules definition for WAF on Azure Front Door: "customRules": [ { "name": "cve202555182", "enabledState": "Enabled", "priority": 1, "ruleType": "MatchRule", "rateLimitDurationInMinutes": 1, "rateLimitThreshold": 100, "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "next-action", "operator": "Any", "negateCondition": false, "matchValue": [], "transforms": [] }, { "matchVariable": "RequestHeader", "selector": "content-type", "operator": "Contains", "negateCondition": false, "matchValue": [ "multipart/form-data", "application/x-www-form-urlencoded" ], "transforms": [ "Lowercase" ] }, { "matchVariable": "RequestBody", "operator": "Contains", "negateCondition": false, "matchValue": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] } ], "action": "Block", "groupBy": [] }, { "name": "cve202555182ver2", "enabledState": "Enabled", "priority": 2, "ruleType": "MatchRule", "rateLimitDurationInMinutes": 1, "rateLimitThreshold": 100, "matchConditions": [ { "matchVariable": "RequestHeader", "selector": "rsc-action-id", "operator": "Any", "negateCondition": false, "matchValue": [], "transforms": [] }, { "matchVariable": "RequestHeader", "selector": "content-type", "operator": "Contains", "negateCondition": false, "matchValue": [ "multipart/form-data", "application/x-www-form-urlencoded" ], "transforms": [ "Lowercase" ] }, { "matchVariable": "RequestBody", "operator": "Contains", "negateCondition": false, "matchValue": [ "constructor", "__proto__", "prototype", "_response" ], "transforms": [ "Lowercase", "UrlDecode", "RemoveNulls" ] } ], "action": "Block", "groupBy": [] } ] Built-in protection with Default Rule Set (DRS) 2.1 Azure WAF’s latest Default Rule Set, DRS 2.1, is able to detect some exploitation attempts related to CVE-2025-55182. In some cases, you may see detections raised by SQL injection rules, even though this CVE is not an SQL injection vulnerability. However, for full mitigation, it is required deploy the dedicated CVE-specific custom rules. You can find more information about Custom Rules on Azure WAF for Application Gateway here or for Azure Front Door here. Changelog 12/7/2025 23:30 PST - Updated custom rules to detect additional attack permutation 12/5/2025 17:45 PST - Updated custom rules to include additional transform "RemoveNulls".How Azure network security can help you meet NIS2 compliance
With the adoption of the NIS2 Directive EU 2022 2555, cybersecurity obligations for both public and private sector organizations have become more strict and far reaching. NIS2 aims to establish a higher common level of cybersecurity across the European Union by enforcing stronger requirements on risk management, incident reporting, supply chain protection, and governance. If your organization runs on Microsoft Azure, you already have powerful services to support your NIS2 journey. In particular Azure network security products such as Azure Firewall, Azure Web Application Firewall WAF, and Azure DDoS Protection provide foundational controls. The key is to configure and operate them in a way that aligns with the directive’s expectations. Important note This article is a technical guide based on the NIS2 Directive EU 2022 2555 and Microsoft product documentation. It is not legal advice. For formal interpretations, consult your legal or regulatory experts. What is NIS2? NIS2 replaces the original NIS Directive 2016 and entered into force on 16 January 2023. Member states must transpose it into national law by 17 October 2024. Its goals are to: Expand the scope of covered entities essential and important entities Harmonize cybersecurity standards across member states Introduce stricter supervisory and enforcement measures Strengthen supply chain security and reporting obligations Key provisions include: Article 20 management responsibility and governance Article 21 cybersecurity risk management measures Article 23 incident notification obligations These articles require organizations to implement technical, operational, and organizational measures to manage risks, respond to incidents, and ensure leadership accountability. Where Azure network security fits The table below maps common NIS2 focus areas to Azure network security capabilities and how they support compliance outcomes. NIS2 focus area Azure services and capabilities How this supports compliance Incident handling and detection Azure Firewall Premium IDPS and TLS inspection, Threat Intelligence mode, Azure WAF managed rule sets and custom rules, Azure DDoS Protection, Azure Bastion diagnostic logs Detect, block, and log threats across layers three to seven. Provide telemetry for triage and enable response workflows that are auditable. Business continuity and resilience Azure Firewall availability zones and autoscale, Azure Front Door or Application Gateway WAF with zone redundant deployments, Azure Monitor with Log Analytics, Traffic Manager or Front Door for failover Improve service availability and provide data for resilience reviews and disaster recovery scenarios. Access control and segmentation Azure Firewall policy with DNAT, network, and application rules, NSGs and ASGs, Azure Bastion for browser based RDP SSH without public IPs, Private Link Enforce segmentation and isolation of critical assets. Support Zero Trust and least privilege for inbound and egress. Vulnerability and misconfiguration defense Azure WAF Microsoft managed rule set based on OWASP CRS. Azure Firewall Premium IDPS signatures Reduce exposure to common web exploits and misconfigurations for public facing apps and APIs. Encryption and secure communications TLS policy: Application Gateway SSL policy; Front Door TLS policy; App Service/PaaS minimum TLS. Inspection: Azure Firewall Premium TLS inspection Inspect and enforce encrypted communication policies and block traffic that violates TLS requirements. Inspect decrypted traffic for threats. Incident reporting and evidence Azure Network Security diagnostics, Log Analytics, Microsoft Sentinel incidents, workbooks, and playbooks Capture and retain telemetry. Correlate events, create incident timelines, and export reports to meet regulator timelines. NIS2 articles in practice Article 21 cybersecurity risk management measures Azure network controls contribute to several required measures: Prevention and detection. Azure Firewall blocks unauthorized access and inspects traffic with IDPS. Azure DDoS Protection mitigates volumetric and protocol attacks. Azure WAF prevents common web exploits based on OWASP guidance. Logging and monitoring. Azure Firewall, WAF, DDoS, and Bastion resources produce detailed resource logs and metrics in Azure Monitor. Ingest these into Microsoft Sentinel for correlation, analytics rules, and automation. Control of encrypted communications. Azure Firewall Premium provides TLS inspection to reveal malicious payloads inside encrypted sessions. Supply chain and service provider management. Use Azure Policy and Defender for Cloud to continuously assess configuration and require approved network security baselines across subscriptions and landing zones. Article 23 incident notification Build an evidence friendly workflow with Sentinel: Early warning within twenty four hours. Use Sentinel analytics rules on Firewall, WAF, DDoS, and Bastion logs to generate incidents and trigger playbooks that assemble an initial advisory. Incident notification within seventy two hours. Enrich the incident with additional context such as mitigation actions from DDoS, Firewall and WAF. Final report within one month. Produce a summary that includes root cause, impact, and corrective actions. Use Workbooks to export charts and tables that back up your narrative. Article 20 governance and accountability Management accountability. Track policy compliance with Azure Policy initiatives for Firewall, DDoS and WAF. Use exemptions rarely and record justification. Centralized visibility. Defender for Cloud’s network security posture views and recommendations give executives and owners a quick view of exposure and misconfigurations. Change control and drift prevention. Manage Firewall, WAF, and DDoS through Network Security Hub and Infrastructure as Code with Bicep or Terraform. Require pull requests and approvals to enforce four eyes on changes. Network security baseline Use this blueprint as a starting point. Adapt to your landing zone architecture and regulator guidance. Topology and control plane Hub and spoke architecture with a centralized Azure Firewall Premium in the hub. Enable availability zones. Deploy Azure Bastion Premium in the hub or a dedicated management VNet; peer to spokes. Remove public IPs from management NICs and disable public RDP SSH on VMs. Use Network Security Hub for at-scale management. Require Infrastructure as Code for all network security resources. Web application protection Protect public apps with Azure Front Door Premium WAF where edge inspection is required. Use Application Gateway WAF v2 for regional scenarios. Enable the Microsoft managed rule set and the latest version. Add custom rules for geo based allow or deny and bot management. enable rate limiting when appropriate. DDoS strategy Enable DDoS Network Protection on virtual networks that contain internet facing resources. Use IP Protection for single public IP scenarios. Configure DDoS diagnostics and alerts. Stream to Sentinel. Define runbooks for escalation and service team engagement. Firewall policy Enable IDPS in alert and then in alert and deny for high confidence signatures. Enable TLS inspection for outbound and inbound where supported. Enforce FQDN and URL filtering for egress. Require explicit allow lists for critical segments. Deny inbound RDP SSH from the internet. Allow management traffic only from Bastion subnets or approved management jump segments. Logging, retention, and access Turn on diagnostic settings for Firewall, WAF, DDoS, and Application Gateway or Front Door. Send to Log Analytics and an archive storage account for long term retention. Set retention per national law and internal policy. Azure Monitor Log Analytics supports table-level retention and archive for up to 12 years, many teams keep a shorter interactive window and multi-year archive for audits. Restrict access with Azure RBAC and Customer Managed Keys where applicable. Automation and playbooks Build Sentinel playbooks for regulator notifications, ticket creation, and evidence collection. Maintain dry run versions for exercises. Add analytics for Bastion session starts to sensitive VMs, excessive failed connection attempts, and out of hours access. Conclusion Azure network security services provide the technical controls most organizations need in order to align with NIS2. When combined with policy enforcement, centralized logging, and automated detection and response, they create a defensible and auditable posture. Focus on layered protection, secure connectivity, and real time response so that you can reduce exposure to evolving threats, accelerate incident response, and meet NIS2 obligations with confidence. References NIS2 primary source Directive (EU) 2022/2555 (NIS2). https://eur-lex.europa.eu/eli/dir/2022/2555/oj/eng Azure Firewall Premium features (TLS inspection, IDPS, URL filtering). https://learn.microsoft.com/en-us/azure/firewall/premium-features Deploy & configure Azure Firewall Premium. https://learn.microsoft.com/en-us/azure/firewall/premium-deploy IDPS signature categories reference. https://learn.microsoft.com/en-us/azure/firewall/idps-signature-categories Monitoring & diagnostic logs reference. https://learn.microsoft.com/en-us/azure/firewall/monitor-firewall-reference Web Application Firewall WAF on Azure Front Door overview & features. https://learn.microsoft.com/en-us/azure/frontdoor/web-application-firewall WAF on Application Gateway overview. https://learn.microsoft.com/en-us/azure/web-application-firewall/overview Examine WAF logs with Log Analytics. https://learn.microsoft.com/en-us/azure/application-gateway/log-analytics Rate limiting with Front Door WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-rate-limit Azure DDoS Protection Service overview & SKUs (Network Protection, IP Protection). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-protection-overview Quickstart: Enable DDoS IP Protection. https://learn.microsoft.com/en-us/azure/ddos-protection/manage-ddos-ip-protection-portal View DDoS diagnostic logs (Notifications, Mitigation Reports/Flows). https://learn.microsoft.com/en-us/azure/ddos-protection/ddos-view-diagnostic-logs Azure Bastion Azure Bastion overview and SKUs. https://learn.microsoft.com/en-us/azure/bastion/bastion-overview Deploy and configure Azure Bastion. https://learn.microsoft.com/en-us/azure/bastion/tutorial-create-host-portal Disable public RDP and SSH on Azure VMs. https://learn.microsoft.com/en-us/azure/virtual-machines/security-baseline Azure Bastion diagnostic logs and metrics. https://learn.microsoft.com/en-us/azure/bastion/bastion-diagnostic-logs Microsoft Sentinel Sentinel documentation (onboard, analytics, automation). https://learn.microsoft.com/en-us/azure/sentinel/ Azure Firewall solution for Microsoft Sentinel. https://learn.microsoft.com/en-us/azure/firewall/firewall-sentinel-overview Use Microsoft Sentinel with Azure WAF. https://learn.microsoft.com/en-us/azure/web-application-firewall/waf-sentinel Architecture & routing Hub‑spoke network topology (reference). https://learn.microsoft.com/en-us/azure/architecture/networking/architecture/hub-spoke Azure Firewall Manager & secured virtual hub. https://learn.microsoft.com/en-us/azure/firewall-manager/secured-virtual-hub
Delivering web applications over IPv6
The IPv4 address space pool has been exhausted for some time now, meaning there is no new public address space available for allocation from Internet Registries. The internet continues to run on IPv4 through technical measures such as Network Address Translation (NAT) and Carrier Grade NAT, and reallocation of address space through IPv4 address space trading. IPv6 will ultimately be the dominant network protocol on the internet, as IPv4 life-support mechanisms used by network operators, hosting providers and ISPs will eventually reach the limits of their scalability. Mobile networks are already changing to IPv6-only APNs; reachability of IPv4-only destinations from these mobile network is through 6-4 NAT gateways, which sometimes causes problems. Client uptake of IPv6 is progressing steadily. Google reports 49% of clients connecting to its services over IPv6 globally, with France leading at 80%. IPv6 client access measured by Google: Meanwhile, countries around the world are requiring IPv6 reachability for public web services. Examples are the United States, European Union member states among which the Netherlands and Norway, and India, and Japan. IPv6 adoption per country measured by Google: Entities needing to comply with these mandates are looking at Azure's networking capabilities for solutions. Azure supports IPv6 for both private and public networking, and capabilities have developed and expanded over time. This article discusses strategies to build and deploy IPv6-enabled public, internet-facing applications that are reachable from IPv6(-only) clients. Azure Networking IPv6 capabilities Azure's private networking capabilities center on Virtual Networks (VNETs) and the components that are deployed within. Azure VNETs are IPv4/IPv6 dual stack capable: a VNET must always have IPv4 address space allocated, and can also have IPv6 address space. Virtual machines in a dual stack VNET will have both an IPv4 and an IPv6 address from the VNET range, and can be behind IPv6 capable External- and Internal Load Balancers. VNETs can be connected through VNET peering, which effectively turns the peered VNETs into a single routing domain. It is now possible to peer only the IPv6 address spaces of VNETs, so that the IPv4 space assigned to VNETs can overlap and communication across the peering is over IPv6. The same is true for connectivity to on-premise over ExpressRoute: the Private Peering can be enabled for IPv6 only, so that VNETs in Azure do not have to have unique IPv4 address space assigned, which may be in short supply in an enterprise. Not all internal networking components are IPv6 capable yet. Most notable exceptions are VPN Gateway, Azure Firewall and Virtual WAN; IPv6 compatibility is on the roadmap for these services, but target availability dates have not been communicated. But now let's focus on Azure's externally facing, public, network services. Azure is ready to let customers publish their web applications over IPv6. IPv6 capable externally facing network services include: - Azure Front Door - Application Gateway - External Load Balancer - Public IP addresses and Public IP address prefixes - Azure DNS - Azure DDOS Protection - Traffic Manager - App Service (IPv6 support is in public preview) IPv6 Application Delivery IPv6 Application Delivery refers to the architectures and services that enable your web application to be accessible via IPv6. The goal is to provide an IPv6 address and connectivity for clients, while often continuing to run your application on IPv4 internally. Key benefits of adopting IPv6 in Azure include: ✅ Expanded Client Reach: IPv4-only websites risk being unreachable to IPv6-only networks. By enabling IPv6, you expand your reach into growing mobile and IoT markets that use IPv6 by default. Governments and enterprises increasingly mandate IPv6 support for public-facing services. ✅Address Abundance & No NAT: IPv6 provides a virtually unlimited address pool, mitigating IPv4 exhaustion concerns. This abundance means each service can have its own public IPv6 address, often removing the need for complex NAT schemes. End-to-end addressing can simplify connectivity and troubleshooting. ✅ Dual-Stack Compatibility: Azure supports dual-stack deployments where services listen on both IPv4 and IPv6. This allows a single application instance or endpoint to serve both types of clients seamlessly. Dual-stack ensures you don’t lose any existing IPv4 users while adding IPv6 capability. ✅Performance and Future Services: Some networks and clients might experience better performance over IPv6. Also, being IPv6-ready prepares your architecture for future Azure features and services as IPv6 integration deepens across the platform. General steps to enable IPv6 connectivity for a web application in Azure are: Plan and Enable IPv6 Addressing in Azure: Define an IPv6 address space in your Azure Virtual Network. Azure allows adding IPv6 address space to existing VNETs, making them dual-stack. A /56 segment for the VNET is recommended, /64 segment for subnets are required (Azure requires /64 subnets). If you have existing infrastructure, you might need to create new subnets or migrate resources, especially since older Application Gateway v1 instances cannot simply be “upgraded” to dual-stack. Deploy or Update Frontend Services with IPv6: Choose a suitable Azure service (Application Gateway, External / Global Load Balancer, etc.) and configure it with a public IPv6 address on the frontend. This usually means selecting *Dual Stack* configuration so the service gets both an IPv4 and IPv6 public IP. For instance, when creating an Application Gateway v2, you would specify IP address type: DualStack (IPv4 & IPv6). Azure Front Door by default provides dual-stack capabilities with its global endpoints. Configure Backends and Routing: Usually your backend servers or services will remain on IPv4. At the time of writing this in October 2025, Azure Application Gateway does not support IPv6 for backend pool addresses. This is fine because the frontend terminates the IPv6 network connection from the client, and the backend initiates an IPv4 connection to the backend pool or origin. Ensure that your load balancing rules, listener configurations, and health probes are all set up to route traffic to these backends. Both IPv4 and IPv6 frontend listeners can share the same backend pool. Azure Front Door does support IPv6 origins. Update DNS Records: Publish a DNS AAAA record for your application’s host name, pointing to the new IPv6 address. This step is critical so that IPv6-only clients can discover the IPv6 address of your service. If your service also has an IPv4 address, you will have both A (IPv4) and AAAA (IPv6) records for the same host name. DNS will thus allow clients of either IP family to connect. (In multi-region scenarios using Traffic Manager or Front Door, DNS configuration might be handled through those services as discussed later). Test IPv6 Connectivity: Once set up, test from an IPv6-enabled network or use online tools to ensure the site is reachable via IPv6. Azure’s services like Application Gateway and Front Door will handle the dual-stack routing, but it’s good to verify that content loads on an IPv6-only connection and that SSL certificates, etc., work over IPv6 as they do for IPv4. Next, we explore specific Azure services and architectures for IPv6 web delivery in detail. External Load Balancer - single region Azure External Load Balancer (also known as Public Load Balancer) can be deployed in a single region to provide IPv6 access to applications running on virtual machines or VM scale sets. External Load Balancer acts as a Layer 4 entry point for IPv6 traffic, distributing connections across backend instances. This scenario is ideal when you have stateless applications or services that do not require Layer 7 features like SSL termination or path-based routing. Key IPv6 Features of External Load Balancer: - Dual-Stack Frontend: Standard Load Balancer supports both IPv4 and IPv6 frontends simultaneously. When configured as dual-stack, the load balancer gets two public IP addresses – one IPv4 and one IPv6 – and can distribute traffic from both IP families to the same backend pool. - Zone-Redundant by Default: Standard Load Balancer is zone-redundant by default, providing high availability across Azure Availability Zones within a region without additional configuration. - IPv6 Frontend Availability: IPv6 support in Standard Load Balancer is available in all Azure regions. Basic Load Balancer does not support IPv6, so you must use Standard SKU. - IPv6 Backend Pool Support: While the frontend accepts IPv6 traffic, the load balancer will not translate IPv6 to IPv4. Backend pool members (VMs) must have private IPv6 addresses. You will need to add private IPv6 addressing to your existing VM IPv4-only infrastructure. This is in contrast to Application Gateway, discussed below, which will terminate inbound IPv6 network sessions and connect to the backend-end over IPv4. - Protocol Support: Supports TCP and UDP load balancing over IPv6, making it suitable for web applications and APIs, but also for non-web TCP- or UDP-based services accessed by IPv6-only clients. To set up an IPv6-capable External Load Balancer in one region, follow this high-level process: Enable IPv6 on the Virtual Network: Ensure the VNET where your backend VMs reside has an IPv6 address space. Add a dual-stack address space to the VNET (e.g., add an IPv6 space like 2001:db8:1234::/56 to complement your existing IPv4 space). Configure subnets that are dual-stack, containing both IPv4 and IPv6 prefixes (/64 for IPv6). Create Standard Load Balancer with IPv6 Frontend: In the Azure Portal, create a new Standard Load Balancer. During creation, configure the frontend IP with both IPv4 and IPv6 public IP addresses. Create or select existing Standard SKU public IP resources – one for IPv4 and one for IPv6. Configure Backend Pool: Add your virtual machines or VM scale set instances to the backend pool. Note that your backend instances will need to have private IPv6 addresses, in addition to IPv4 addresses, to receive inbound IPv6 traffic via the load balancer. Set Up Load Balancing Rules: Create load balancing rules that map frontend ports to backend ports. For web applications, typically map port 80 (HTTP) and 443 (HTTPS) from both the IPv4 and IPv6 frontends to the corresponding backend ports. Configure health probes to ensure only healthy instances receive traffic. Configure Network Security Groups: Ensure an NSG is present on the backend VM's subnet, allowing inbound traffic from the internet to the port(s) of the web application. Inbound traffic is "secure by default" meaning that inbound connectivity from internet is blocked unless there is an NSG present that explicitly allows it. DNS Configuration: Create DNS records for your application: an A record pointing to the IPv4 address and an AAAA record pointing to the IPv6 address of the load balancer frontend. Outcome: In this single-region scenario, IPv6-only clients will resolve your application's hostname to an IPv6 address and connect to the External Load Balancer over IPv6. Example: Consider a web application running on a VM (or a VM scale set) behind an External Load Balancer in Sweden Central. The VM runs the Azure Region and Client IP Viewer containerized application exposed on port 80, which displays the region the VM is deployed in and the calling client's IP address. The load balancer's front-end IPv6 address has a DNS name of ipv6webapp-elb-swedencentral.swedencentral.cloudapp.azure.com. When called from a client with an IPv6 address, the application shows its region and the client's address. Limitations & Considerations: - Standard SKU Required: Basic Load Balancer does not support IPv6. You must use Standard Load Balancer. - Layer 4 Only: Unlike Application Gateway, External Load Balancer operates at Layer 4 (transport layer). It cannot perform SSL termination, cookie-based session affinity, or path-based routing. If you need these features, consider Application Gateway instead. - Dual stack IPv4/IPv6 Backend required: Backend pool members must have private IPv6 addresses to receive inbound IPv6 traffic via the load balancer. The load balancer does not translate between the IPv6 frontend and an IPv4 backend. - Outbound Connectivity: If your backend VMs need outbound internet access over IPv6, you need to configure an IPv6 outbound rule. Global Load Balancer - multi-region Azure Global Load Balancer (aka Cross-Region Load Balancer) provides a cloud-native global network load balancing solution for distributing traffic across multiple Azure regions. Unlike DNS-based solutions, Global Load Balancer uses anycast IP addressing to automatically route clients to the nearest healthy regional deployment through Microsoft's global network. Key Features of Global Load Balancer: - Static Anycast Global IP: Global Load Balancer provides a single static public IP address (both IPv4 and IPv6 supported) that is advertised from all Microsoft WAN edge nodes globally. This anycast address ensures clients always connect to the nearest available Microsoft edge node without requiring DNS resolution. - Geo-Proximity Routing: The geo-proximity load-balancing algorithm minimizes latency by directing traffic to the nearest region where the backend is deployed. Unlike DNS-based routing, there's no DNS lookup delay - clients connect directly to the anycast IP and are immediately routed to the best region. - Layer 4 Pass-Through: Global Load Balancer operates as a Layer 4 pass-through network load balancer, preserving the original client IP address (including IPv6 addresses) for backend applications to use in their logic. - Regional Redundancy: If one region fails, traffic is automatically routed to the next closest healthy regional load balancer within seconds, providing instant global failover without DNS propagation delays. Architecture Overview: Global Load Balancer sits in front of multiple regional Standard Load Balancers, each deployed in different Azure regions. Each regional load balancer serves a local deployment of your application with IPv6 frontends. The global load balancer provides a single anycast IP address that clients worldwide can use to access your application, with automatic routing to the nearest healthy region. Multi-Region Deployment Steps: Deploy Regional Load Balancers: Create Standard External Load Balancers in multiple Azure regions (e.g. Sweden Central, East US2). Configure each with dual-stack frontends (IPv4 and IPv6 public IPs) and connect them to regional VM deployments or VM scale sets running your application. Configure Global Frontend IP address: Create a Global tier public IPv6 address for the frontend, in one of the supported Global Load Balancer home regions . This becomes your application's global anycast address. Create Global Load Balancer: Deploy the Global Load Balancer in the same home region. The home region is where the global load balancer resource is deployed - it doesn't affect traffic routing. Add Regional Backends: Configure the backend pool of the Global Load Balancer to include your regional Standard Load Balancers. Each regional load balancer becomes an endpoint in the global backend pool. The global load balancer automatically monitors the health of each regional endpoint. Set Up Load Balancing Rules: Create load balancing rules mapping frontend ports to backend ports. For web applications, typically map port 80 (HTTP) and 443 (HTTPS). The backend port on the global load balancer must match the frontend port of the regional load balancers. Configure Health Probes: Global Load Balancer automatically monitors the health of regional load balancers every 5 seconds. If a regional load balancer's availability drops to 0, it is automatically removed from rotation, and traffic is redirected to other healthy regions. DNS Configuration: Create DNS records pointing to the global load balancer's anycast IP addresses. Create both A (IPv4) and AAAA (IPv6) records for your application's hostname pointing to the global load balancer's static IPs. Outcome: IPv6 clients connecting to your application's hostname will resolve to the global load balancer's anycast IPv6 address. When they connect to this address, the Microsoft global network infrastructure automatically routes their connection to the nearest participating Azure region. The regional load balancer then distributes the traffic across local backend instances. If that region becomes unavailable, subsequent connections are automatically routed to the next nearest healthy region. Example: Our web application, which displays the region it is in, and the calling client's IP address, now runs on VMs behind External Load Balancers in Sweden Central and East US2. The External Load Balancer's front-ends are in the backend pool of a Global Load Balancer, which has a Global tier front-end IPv6 address. The front-end has an FQDN of `ipv6webapp-glb.eastus2.cloudapp.azure.com` (the region designation `eastus2` in the FQDN refers to the Global Load Balancer's "home region", into which the Global tier public IP must be deployed). When called from a client in Europe, Global Load Balancer directs the request to the instance deployed in Sweden Central. When called from a client in the US, Global Load Balancer directs the request to the instance deployed in US East 2. Features: - Client IP Preservation: The original IPv6 client address is preserved and available to backend applications, enabling IP-based logic and compliance requirements. - Floating IP Support: Configure floating IP at the global level for advanced networking scenarios requiring direct server return or high availability clustering. - Instant Scaling: Add or remove regional deployments behind the global endpoint without service interruption, enabling dynamic scaling for traffic events. - Multiple Protocol Support: Supports both TCP and UDP traffic distribution across regions, suitable for various application types beyond web services. Limitations & Considerations: - Home Region Requirement: Global Load Balancer can only be deployed in specific home regions, though this doesn't affect traffic routing performance. - Public Frontend Only: Global Load Balancer currently supports only public frontends - internal/private global load balancing is not available. - Standard Load Balancer Backends: Backend pool can only contain Standard Load Balancers, not Basic Load Balancers or other resource types. - Same IP Version Requirement: NAT64 translation isn't supported - frontend and backend must use the same IP version (IPv4 or IPv6). - Port Consistency: Backend port on global load balancer must match the frontend port of regional load balancers for proper traffic flow. - Health Probe Dependencies: Regional load balancers must have proper health probes configured for the global load balancer to accurately assess regional health. Comparison with DNS-Based Solutions: Unlike Traffic Manager or other DNS-based global load balancing solutions, Global Load Balancer provides: - Instant Failover: No DNS TTL delays - failover happens within seconds at the network level. - True Anycast: Single IP address that works globally without client-side DNS resolution. - Consistent Performance: Geo-proximity routing through Microsoft's backbone network ensures optimal paths. - Simplified Management: No DNS record management or TTL considerations. This architecture delivers global high availability and optimal performance for IPv6 applications through anycast routing, making it a good solution for latency-sensitive applications requiring worldwide accessibility with near-instant regional failover. Application Gateway - single region Azure Application Gateway can be deployed in a single region to provide IPv6 access to applications in that region. Application Gateway acts as the entry point for IPv6 traffic, terminating HTTP/S from IPv6 clients and forwarding to backend servers over IPv4. This scenario works well when your web application is served from one Azure region and you want to enable IPv6 connectivity for it. Key IPv6 Features of Application Gateway (v2 SKU): - Dual-Stack Frontend: Application Gateway v2 supports both [IPv4 and IPv6 frontends](https://learn.microsoft.com/en-us/azure/application-gateway/application-gateway-faq). When configured as dual-stack, the gateway gets two IP addresses – one IPv4 and one IPv6 – and can listen on both. (IPv6-only is not supported; IPv4 is always paired). IPv6 support requires Application Gateway v2, v1 does not support IPv6. - No IPv6 on Backends: The backend pool must use IPv4 addresses. IPv6 addresses for backend servers are currently not supported. This means your web servers can remain on IPv4 internal addresses, simplifying adoption because you only enable IPv6 on the frontend. - WAF Support: The Application Gateway Web Application Firewall (WAF) will inspect IPv6 client traffic just as it does IPv4. Single Region Deployment Steps: To set up an IPv6-capable Application Gateway in one region, consider the following high-level process: Enable IPv6 on the Virtual Network: Ensure the region’s VNET where the Application Gateway will reside has an IPv6 address space. Configure a subnet for the Application Gateway that is dual-stack (contains both an IPv4 subnet prefix and an IPv6 /64 prefix). Deploy Application Gateway (v2) with Dual Stack Frontend: Create a new Application Gateway using the Standard_v2 or WAF_v2 SKU. Populate Backend Pool: Ensure your backend pool (the target application servers or service) contains (DNS names pointing to) IPv4 addresses of your actual web servers. IPv6 addresses are not supported for backends. Configure Listeners and Rules: Set up listeners on the Application Gateway for your site. When creating an HTTP(S) listener, you choose which frontend IP to use – you would create one listener for IPv4 address and one for IPv6. Both listeners can use the same domain name (hostname) and the same underlying routing rule to your backend pool. Testing and DNS: After the gateway is deployed and configured, note the IPv6 address of the frontend (you can find it in the Gateway’s overview or in the associated Public IP resource). Update your application’s DNS records: create an AAAA record pointing to this IPv6 address (and update the A record to point to the IPv4 if it changed). With DNS in place, test the application by accessing it from an IPv6-enabled client or tool. Outcome: In this single-region scenario, IPv6-only clients will resolve your website’s hostname to an IPv6 address and connect to the Application Gateway over IPv6. The Application Gateway then handles the traffic and forwards it to your application over IPv4 internally. From the user perspective, the service now appears natively on IPv6. Importantly, this does not require any changes to the web servers, which can continue using IPv4. Application Gateway will include the source IPv6 address in an X-Forwarded-For header, so that the backend application has visibility of the originating client's address. Example: Our web application, which displays the region it is deployed in and the calling client's IP address, now runs on a VM behind Application Gateway in Sweden Central. The front-end has an FQDN of `ipv6webapp-appgw-swedencentral.swedencentral.cloudapp.azure.com`. Application Gateway terminates the IPv6 connection from the client and proxies the traffic to the application over IPv4. The client's IPv6 address is passed in the X-Forwarded-For header, which is read and displayed by the application. Calling the application's API endpoint at `/api/region` shows additional detail, including the IPv4 address of the Application Gateway instance that initiates the connection to the backend, and the original client IPv6 address (with the source port number appended) preserved in the X-Forwarded-For header. { "region": "SwedenCentral", "clientIp": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21:60769", "xForwardedFor": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21:60769", "remoteAddress": "::ffff:10.1.0.4", "isPrivateIP": false, "expressIp": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21:60769", "connectionInfo": { "remoteAddress": "::ffff:10.1.0.4", "remoteFamily": "IPv6", "localAddress": "::ffff:10.1.1.68", "localPort": 80 }, "allHeaders": { "x-forwarded-for": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21:60769" }, "deploymentAdvice": "Public IP detected successfully" } Limitations & Considerations: - Application Gateway v1 SKUs are not supported for IPv6. If you have an older deployment on v1, you’ll need to migrate to v2. - IPv6-only Application Gateway is not allowed. You must have IPv4 alongside IPv6 (the service must be dual-stack). This is usually fine, as dual-stack ensures all clients are covered. - No IPv6 backend addresses: The backend pool must have IPv4 addresses. - Management and Monitoring: Application Gateway logs traffic from IPv6 clients to Log Analytics (the client IP field will show IPv6 addresses). - Security: Azure’s infrastructure provides basic DDoS protection for IPv6 endpoints just as for IPv4. However, it is highly recommended to deploy Azure DDoS Protection Standard: this provides enhanced mitigation tailored to your specific deployment. Consider using the Web Application Firewall function for protection against application layer attacks. Application Gateway - multi-region Mission-critical web applications should be deploy in multiple Azure regions, achieving higher availability and lower latency for users worldwide. In a multi-region scenario, you need a mechanism to direct IPv6 client traffic to the “nearest” or healthiest region. Azure Application Gateway by itself is a regional service, so to use it in multiple regions, we use Azure Traffic Manager for global DNS load balancing, or use Azure Front Door (covered in the next section) as an alternative. This section focuses on the Traffic Manager + Application Gateway approach to multi-region IPv6 delivery. Azure Traffic Manager is a DNS-based load balancer that can distribute traffic across endpoints in different regions. It works by responding to DNS queries with the appropriate endpoint FQDN or IP, based on the routing method (Performance, Priority, Geographic) configured. Traffic Manager is agnostic to the IP version: it either returns CNAMEs, or AAAA records for IPv6 endpoints and A records for IPv4. This makes it suitable for routing IPv6 traffic globally. Architecture Overview: Each region has its own dual-stack Application Gateway. Traffic Manager is configured with an endpoint entry for each region’s gateway. The application’s FQDN is now a domain name hosted by Traffic Manager such as ipv6webapp.traffimanager.net, or a CNAME that ultimately points to it. DNS resolution will go through Traffic Manager, which decides which regional gateway’s FQDN to return. The client then connects directly to that Application Gateway’s IPv6 address, as follows: 1. DNS query: Client asks for ipv6webapp.trafficmanager.net, which is hosted in a Traffic Manager profile. 2. Traffic Manager decision: Traffic Manager sees an incoming DNS request and chooses the best endpoint (say, Sweden Central) based on routing rules (e.g., geographic proximity or lowest latency). 3. Traffic Manager response: Traffic Manager returns the FQDN of the Sweden Central Application Gateway to the client. 4. DNS Resolution: The client resolves regional FQDN and receives a AAAA response containing the IPv6 address. 5. Client connects: The client’s browser connects to the West Europe App Gateway IPv6 address directly. The HTTP/S session is established via IPv6 to that regional gateway, which then handles the request. 6. Failover: If that region becomes unavailable, Traffic Manager’s health checks will detect it and subsequent DNS queries will be answered with the FQDN of the secondary region’s gateway. Deployment Steps for Multi-Region with Traffic Manager: Set up Dual-Stack Application Gateways in each region: Similar to the single-region case, deploy an Azure Application Gateway v2 in each desired region (e.g., one in North America, one in Europe). Configure the web application in each region, these should be parallel deployments serving the same content. Configure a Traffic Manager Profile: In Azure Traffic Manager, create a profile and choose a routing method (such as Performance for nearest region routing, or Priority for primary/backup failover). Add endpoints for each region. Since our endpoints are Azure services with IPs, we can either use Azure endpoints (if the Application Gateways have Azure-provided DNS names) or External endpoints using the IP addresses. The simplest way is to use the Public IP resource of each Application Gateway as an Azure endpoint – ensure each App Gateway’s public IP has a DNS label (so it has a FQDN). Traffic Manager will detect those and also be aware of their IPs. Alternatively, use the IPv6 address as an External endpoint directly. Traffic Manager allows IPv6 addresses and will return AAAA records for them. DNS Setup: Traffic Manager profiles have a FQDN (like ipv6webapp.trafficmanager.net). You can either use that as your service’s CNAME, or you can configure your custom domain to CNAME to the Traffic Manager profile. Health Probing: Traffic Manager continuously checks the health of endpoints. When endpoints are Azure App Gateways, it uses HTTP/S probes to a specified URI path, to each gateway’s address. Make sure each App Gateway has a listener on the probing endpoint (e.g., a health check page) and that health probes are enabled. Testing Failover and Distribution: Test the setup by querying DNS from different geographical locations (to see if you get the nearest region’s IP). Also simulate a region down (stop the App Gateway or backend) and observe if Traffic Manager directs traffic to the other region. Because DNS TTLs are involved, failover isn’t instant but typically within a couple of minutes depending on TTL and probe interval. Considerations in this Architecture: - Latency vs Failover: Traffic Manager as a DNS load balancer directs users at connect time, but once a client has an answer (IP address), it keeps sending to that address until the DNS record TTL expires and it re-resolves. This is fine for most web apps. Ensure the TTL in the Traffic Manager profile is not too high (the default is 30 seconds). - IPv6 DNS and Connectivity: Confirm that each region’s IPv6 address is correctly configured and reachable globally. Azure’s public IPv6 addresses are globally routable. Traffic Manager itself is a global service and fully supports IPv6 in its decision-making. - Cost: Using multiple Application Gateways and Traffic Manager incurs costs for each component (App Gateway is per hour + capacity unit, Traffic Manager per million DNS queries). This is a trade-off for high availability. - Alternative: Azure Front Door: Azure Front Door is an alternative to the Traffic Manager + Application Gateway combination. Front Door can automatically handle global routing and failover at layer 7 without DNS-based limitations, offering potentially faster failover. Azure Front Door is discussed in the next section. In summary, a multi-region IPv6 web delivery with Application Gateways uses Traffic Manager for global DNS load balancing. Traffic Manager will seamlessly return IPv6 addresses for IPv6 clients, ensuring that no matter where an IPv6-only client is, they get pointed to the nearest available regional deployment of your app. This design achieves global resiliency (withstand a regional outage) and low latency access, leveraging IPv6 connectivity on each regional endpoint. Example: The global FQDN of our application is now ipv6webapp.trafficmanager.net and clients will use this FQDN to access the application regardless of their geographical location. Traffic Manager will return the FQDN of one of the regional deployments, `ipv6webapp-appgw-swedencentral.swedencentral.cloudapp.azure.com` or `ipv6webappr2-appgw-eastus2.eastus2.cloudapp.azure.com` depending on the routing method configured, the health state of the regional endpoints and the client's location. Then the client resolves the regional FQDN through its local DNS server and connects to the regional instance of the application. DNS resolution from a client in Europe: Resolve-DnsName ipv6webapp.trafficmanager.net Name Type TTL Section NameHost ---- ---- --- ------- -------- ipv6webapp.trafficmanager.net CNAME 59 Answer ipv6webapp-appgw-swedencentral.swedencentral.cloudapp.azure.com Name : ipv6webapp-appgw-swedencentral.swedencentral.cloudapp.azure.com QueryType : AAAA TTL : 10 Section : Answer IP6Address : 2603:1020:1001:25::168 And from a client in the US: Resolve-DnsName ipv6webapp.trafficmanager.net Name Type TTL Section NameHost ---- ---- --- ------- -------- ipv6webapp.trafficmanager.net CNAME 60 Answer ipv6webappr2-appgw-eastus2.eastus2.cloudapp.azure.com Name : ipv6webappr2-appgw-eastus2.eastus2.cloudapp.azure.com QueryType : AAAA TTL : 10 Section : Answer IP6Address : 2603:1030:403:17::5b0 Azure Front Door Azure Front Door is an application delivery network with built-in CDN, SSL offload, WAF, and routing capabilities. It provides a single, unified frontend distributed across Microsoft’s edge network. Azure Front Door natively supports IPv6 connectivity. For applications that have users worldwide, Front Door offers advantages: - Global Anycast Endpoint: Provides anycast IPv4 and IPv6 addresses, advertised out of all edge locations, with automatic A and AAAA DNS record support. - IPv4 and IPv6 origin support: Azure Front Door supports both IPv4 and IPv6 origins (i.e. backends), both within Azure and externally (i.e. accessible over the internet). - Simplified DNS: Custom domains can be mapped using CNAME records. - Layer-7 Routing: Supports path-based routing and automatic backend health detection. - Edge Security: Includes DDoS protection and optional WAF integration. Front Door enables "cross-IP version" scenario's: a client can connect to the Front Door front-end over IPv6, and then Front Door can connect to an IPv4 origin. Conversely, an IPv4-only client can retrieve content from an IPv6 backend via Front Door. Front Door preserves the client's source IP address in the X-Forwarded-For header. Note: Front Door provides managed IPv6 addresses that are not customer-owned resources. Custom domains should use CNAME records pointing to the Front Door hostname rather than direct IP address references. Private Link Integration Azure Front Door Premium introduces Private Link integration, enabling secure, private connectivity between Front Door and backend resources, without exposing them to the public internet. When Private Link is enabled, Azure Front Door establishes a private endpoint within a Microsoft-managed virtual network. This endpoint acts as a secure bridge between Front Door’s global edge network and your origin resources, such as Azure App Service, Azure Storage, Application Gateway, or workloads behind an internal load balancer. Traffic from end users still enters through Front Door’s globally distributed POPs, benefiting from features like SSL offload, caching, and WAF protection. However, instead of routing to your origin over public, internet-facing, endpoints, Front Door uses the private Microsoft backbone to reach the private endpoint. This ensures that all traffic between Front Door and your origin remains isolated from external networks. The private endpoint connection requires approval from the origin resource owner, adding an extra layer of control. Once approved, the origin can restrict public access entirely, enforcing that all traffic flows through Private Link. Private Link integration brings following benefits: - Enhanced Security: By removing public exposure of backend services, Private Link significantly reduces the risk of DDoS attacks, data exfiltration, and unauthorized access. - Compliance and Governance: Many regulatory frameworks mandate private connectivity for sensitive workloads. Private Link helps meet these requirements without sacrificing global availability. - Performance and Reliability: Traffic between Front Door and your origin travels over Microsoft’s high-speed backbone network, delivering low latency and consistent performance compared to public internet paths. - Defense in Depth: Combined with Web Application Firewall (WAF), TLS encryption, and DDoS protection, Private Link strengthens your security posture across multiple layers. - Isolation and Control: Resource owners maintain control over connection approvals, ensuring that only authorized Front Door profiles can access the origin. - Integration with Hybrid Architectures: For scenarios involving AKS clusters, custom APIs, or workloads behind internal load balancers, Private Link enables secure connectivity without requiring public IPs or complex VPN setups. Private Link transforms Azure Front Door from a global entry point into a fully private delivery mechanism for your applications, aligning with modern security principles and enterprise compliance needs. Example: Our application is now placed behind Azure Front Door. We are combining a public backend endpoint and Private Link integration, to show both in action in a single example. The Sweden Central origin endpoint is the public IPv6 endpoint of the regional External Load Balancers and the origin in US East 2 is connected via Private Link integration The global FQDN `ipv6webapp-d4f4euhnb8fge4ce.b01.azurefd.net` and clients will use this FQDN to access the application regardless of their geographical location. The FQDN resolves to Front Door's global anycast address, and the internet will route client requests to the nearest Microsoft edge from this address is advertised. Front Door will then transparently route the request to the nearest origin deployment in Azure. Although public endpoints are used in this example, that traffic will be route over the Microsoft network. From a client in Europe: Calling the application's api endpoint on `ipv6webapp-d4f4euhnb8fge4ce.b01.azurefd.net/api/region` shows some more detail. { "region": "SwedenCentral", "clientIp": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21", "xForwardedFor": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21", "remoteAddress": "2a01:111:2053:d801:0:afd:ad4:1b28", "isPrivateIP": false, "expressIp": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21", "connectionInfo": { "remoteAddress": "2a01:111:2053:d801:0:afd:ad4:1b28", "remoteFamily": "IPv6", "localAddress": "2001:db8:1:1::4", "localPort": 80 }, "allHeaders": { "x-forwarded-for": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21", "x-azure-clientip": "2001:1c04:3404:9500:fd9b:58f4:1fb2:db21" }, "deploymentAdvice": "Public IP detected successfully" } "remoteAddress": "2a01:111:2053:d801:0:afd:ad4:1b28" is the address from which Front Door sources its request to the origin. From a client in the US: The detailed view shows that the IP address calling the backend instance now is local VNET address. Private Link sources traffic coming in from a local address taken from the VNET it is in. The original client IP address is again preserved in the X-Forwarded-For header. { "region": "eastus2", "clientIp": "2603:1030:501:23::68:55658", "xForwardedFor": "2603:1030:501:23::68:55658", "remoteAddress": "::ffff:10.2.1.5", "isPrivateIP": false, "expressIp": "2603:1030:501:23::68:55658", "connectionInfo": { "remoteAddress": "::ffff:10.2.1.5", "remoteFamily": "IPv6", "localAddress": "::ffff:10.2.2.68", "localPort": 80 }, "allHeaders": { "x-forwarded-for": "2603:1030:501:23::68:55658" }, "deploymentAdvice": "Public IP detected successfully" } Conclusion IPv6 adoption for web applications is no longer optional. It is essential as public IPv4 address space is depleted, mobile networks increasingly use IPv6 only and governments mandate IPv6 reachability for public services. Azure's comprehensive dual-stack networking capabilities provide a clear path forward, enabling organizations to leverage IPv6 externally without sacrificing IPv4 compatibility or requiring complete infrastructure overhauls. Azure's externally facing services — including Application Gateway, External Load Balancer, Global Load Balancer, and Front Door — support IPv6 frontends, while Application Gateway and Front Door maintain IPv4 backend connectivity. This architecture allows applications to remain unchanged while instantly becoming accessible to IPv6-only clients. For single-region deployments, Application Gateway offers layer-7 features like SSL termination and WAF protection. External Load Balancer provides high-performance layer-4 distribution. Multi-region scenarios benefit from Traffic Manager's DNS-based routing combined with regional Application Gateways, or the superior performance and failover capabilities of Global Load Balancer's anycast addressing. Azure Front Door provides global IPv6 delivery with edge optimization, built-in security, and seamless failover across Microsoft's network. Private Link integration allows secure global IPv6 distribution while maintaining backend isolation. The transition to IPv6 application delivery on Azure is straightforward: enable dual-stack addressing on virtual networks, configure IPv6 frontends on load balancing services, and update DNS records. With Application Gateway or Front Door, backend applications require no modifications. These Azure services handle the IPv4-to-IPv6 translation seamlessly. This approach ensures both immediate IPv6 accessibility and long-term architectural flexibility as IPv6 adoption accelerates globally.General Availability of JavaScript Challenge in Azure Front Door WAF
We are pleased to announce the General Availability (GA) of the JavaScript Challenge feature for Azure Web Application Firewall (WAF) on Azure Front Door. This capability equips organizations with a seamless, invisible anti-bot verification layer that distinguishes legitimate users from malicious scripts helping protect web applications from automated threats while preserving a smooth user experience. Azure WAF JavaScript Challenge Modern bot attacks are increasingly evasive, often bypassing traditional defenses like IP based blocking or simple rate limits. The JavaScript Challenge introduces a lightweight, browser-based verification step that helps distinguish legitimate users from automated scripts without requiring user interaction. Benefits of the JavaScript Challenge include: Low friction for legitimate users: Genuine users experience minimal latency or interruption since no manual interaction is required. Stronger bot protection: Automated tools and scripts fail to pass the computational challenge, enabling more effective blocking of bad bots. Flexible enforcement: You can target specific endpoints (e.g., login, registration, checkout flows), apply to bot manager or custom rules, and adjust cookie lifetimes to align with your user experience goals. How JavaScript Challenge Works The JavaScript Challenge is configured as an action in either custom rules or in the Bot Manager ruleset. When a client’s HTTP/S request matches a rule with this action, Azure WAF directs the browser to a lightweight challenge page. The page runs a short computational task automatically usually invisible to the user. If the browser successfully completes the computation, the request is validated and allowed to proceed, confirming that it originated from a legitimate user. If the challenge fails, the request will be blocked, preventing automated bots from accessing the application. Getting Started If you have been using JavaScript Challenge during the public preview, your existing configurations will continue to work. For new users, simply enable the JavaScript Challenge action in your WAF policy and define the triggering conditions. For more details on configuration and best practices, check out our earlier blogs: Azure WAF Public Preview: JavaScript Challenge | Microsoft Community Hub Azure WAF’s Bot Manager 1.1 and JavaScript Challenge: Navigating the Bot Threat Terrain | Microsoft Community Hub Documentation Web Application Firewall JavaScript Challenge | Microsoft LearnGeneral Availability of CAPTCHA in Azure Front Door WAF
We are excited to announce the General Availability (GA) of the Azure Web Application Firewall (WAF) CAPTCHA challenge for Azure Front Door, empowering customers to better defend their web applications against automated bot attacks while ensuring legitimate users can still access their apps seamlessly. This milestone marks the culmination of a successful public preview that saw hundreds of customers defend against more than 700 million bot requests, reinforcing the value of interactive security mechanisms in modern web application protection. Why CAPTCHA Matters Web applications today face an ever-growing array of automated threats - bots, scrapers, credential stuffing, and brute-force attacks - that often bypass traditional defenses like IP blocking and rate limiting. CAPTCHA introduces a human verification layer that helps distinguish legitimate users from malicious automation. With this GA release, Azure Front Door WAF now offers a fully supported CAPTCHA action that can be configured in custom rules or Bot Manager rules. When suspicious traffic matches a CAPTCHA-enabled rule, users are prompted with a visual or audio challenge to verify their identity before proceeding. How CAPTCHA Works When a client request matches a WAF rule that has the CAPTCHA action enabled, Azure WAF displays an interactive CAPTCHA challenge in the browser to verify that the requester is human. If the user successfully solves the CAPTCHA, Azure WAF marks the request as validated and allows it to proceed through the rest of the rule evaluation. Requests that don’t complete the challenge (or fail it) are blocked, stopping automated bots from advancing. What’s New in GA With the GA release, customers can expect: Updated Interstitial Page: The CAPTCHA page now includes refreshed Microsoft branding, delivering a more consistent and trusted experience for users. Enhanced Stability and Performance: Improvements based on feedback from preview deployments to ensure faster response times and smoother user verification experiences. Full Production Support: The feature is now backed by Microsoft’s service-level agreement (SLA) and is recommended for all production workloads. How to Get Started If you have already been using CAPTCHA during the public preview, no action is needed, your configurations will continue to work as expected. For new users, simply enable the CAPTCHA action within your custom rules or managed rule sets and define the triggering conditions. For a deeper dive into how CAPTCHA works and how to configure it, check out our earlier blogs: Securing web applications with Azure Front Door WAF CAPTCHA | Microsoft Community Hub Public Preview of Azure WAF CAPTCHA Challenge for Azure Front Door | Microsoft Community Hub Documentation Azure Front Door Web Application Firewall CAPTCHA | Microsoft LearnSecuring web applications with Azure Front Door WAF CAPTCHA
Introduction Web applications today are constantly under siege from a range of threats, including automated bots and scrapers, as well as credential-focused threats such as credential stuffing and brute-force attacks. As attackers leverage advanced automation and increasingly sophisticated attack methods, organizations need more robust and interactive security measures capable of distinguishing between legitimate users and malicious traffic. To address these evolving challenges, Azure Front Door’s Web Application Firewall (WAF) now introduces CAPTCHA, currently available in public preview. This feature incorporates a critical interactive verification step, validating real human users while blocking automated malicious traffic in real-time. By integrating CAPTCHA directly within the WAF, organizations can secure crucial user flows - such as logins, registrations, and checkout processes - from bots and scripted attacks aiming to compromise credentials, create fraudulent accounts, or harvest data, all while preserving a seamless experience for genuine users. Overview of Azure WAF Front Door CAPTCHA CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) is a security mechanism designed to differentiate human users from automated bots by presenting interactive challenges that only humans can reliably complete. Azure Front Door’s WAF implementation of CAPTCHA delivers this capability seamlessly, integrating directly into web traffic processing to offer real-time protection. Azure Front Door WAF CAPTCHA is a dynamic security challenge automatically triggered when a client's request matches a WAF rule configured with the CAPTCHA action. When activated, users are presented with an interactive CAPTCHA challenge in their browser and can verify themselves either by solving a visual puzzle or completing an audio-based task. Once successfully solved, the user's request proceeds normally, while automated scripts and bots unable to complete the challenge are immediately blocked, effectively preventing malicious traffic. By clearly distinguishing human users from bots, Azure WAF CAPTCHA strengthens application defenses. Key benefits include: Account and Access Protection - Azure WAF CAPTCHA helps protect authentication and user account workflows from automated abuse and unauthorized access. Block Automated Account Creation - Stops bots from registering fake or spam accounts during sign-up. Prevent Account Takeovers - Stop suspicious login attempts to protect against stolen credentials. Stop Brute-Force Logins - Prevents automated password guessing and account breaches Data and Resource Protection - Use CAPTCHA to defend web content and inventory from unauthorized scraping and resource hoarding. Limit Web Scraping - Restricts bots from extracting proprietary data like pricing or content. Prevent Inventory Hoarding - Protects e-commerce and ticketing platforms from bulk purchasing by bots. Fraud and Abuse Prevention – Use CAPTCHA to reduce the risk of automated abuse in transaction and engagement workflows. Block Fake Transactions - Stops abuse of discounts, gift cards, or loyalty programs by scripted bots. Reduce Spam and Abusive Inputs - Ensures form and comment submissions are from real users, not bots. Application-Layer DDoS Defense- Acts as a first line of defense to block high-volume bot requests targeting application resources. Azure WAF Front Door CAPTCHA Key Features Azure WAF CAPTCHA in Azure Front Door is designed to be flexible, easy to configure, and deeply integrated into WAF’s existing policy model. Below are the key features that define how CAPTCHA is activated, managed, and monitored. Policy Settings Azure WAF CAPTCHA includes a configurable policy setting that defines how long a user remains validated after successfully completing a challenge. This is controlled through the CAPTCHA challenge cookie, which is injected into the user's browser upon solving the challenge. The cookie name is afd_azwaf_captcha and it determines how long a user is exempt from repeated challenges. The cookie validity period can be set between 5 and 1,440 minutes, with a default of 30 minutes. Once the cookie expires, the user will be prompted to complete the CAPTCHA again if they trigger a matching rule. This setting helps balance security and user experience by reducing repetitive challenges for legitimate users while still enforcing protection over time. Integration with Bot Manager Rules CAPTCHA can be enabled directly in the Bot Manager rulesets, allowing administrators to apply CAPTCHA as an enforcement action. To enable the CAPTCHA challenge within the Bot Manager's managed rules, users can navigate to the managed rules section in their WAF policy and adjust the actions for each rule group. This setup is ideal for mitigating automated logins, credential stuffing, and other bot-driven behaviors with minimal configuration. Custom Rule Support For more targeted scenarios, CAPTCHA can be configured as the action in a custom rule. This allows precise control over when and where the challenge is triggered - based on URI, method, headers, geo-location, or user-agent patterns. Common examples include applying CAPTCHA to login endpoints, sign-up forms, or regions known for bot traffic. Monitoring Detailed logs and metrics are captured whenever the CAPTCHA challenge is triggered. This allows security administrators to track the CAPTCHA challenges and analyze traffic patterns and security incidents. The “Web Application Firewall CAPTCHA Request Count” metric within Azure Front Door displays the number of CAPTCHA requests evaluated by the Web Application Firewall: When WAF diagnostic logging is enabled, each CAPTCHA event is written to the AzureDiagnostics table. These logs can be queried to see which endpoints triggered challenges, the outcome of each event (Issued, Passed, Valid, or Blocked), the client IP and user agent, and the timestamp of the interaction. By analyzing this data, you can calculate solve rates, identify problem spots where users are repeatedly challenged or blocked, and fine-tune your rules to improve both security and user experience. Pricing Azure Front Door WAF CAPTCHA is currently in public preview and pricing details are available on Pricing - Front Door | Microsoft Azure. Enabling and using the CAPTCHA challenge CAPTCHA in the Bot Manager ruleset As described in the previous section, the CAPTCHA challenge can be enabled within both the Bot Manager ruleset and custom rules. To enable it within the Bot Manager ruleset, simply navigate to the Managed Rules section of your WAF policy in Azure Front Door, select the Bot Manager rule you want to configure, and change the action to CAPTCHA challenge. Within the Policy Settings, you can adjust the CAPTCHA challenge cookie’s validity period, with options ranging from 5 to 1,440 minutes. To demonstrate how Azure WAF Front Door issues a CAPTCHA challenge via a Bot Manager rule, we will simulate bot-like requests using PowerShell. In our setup, we have configured Azure Front Door with a WAF Policy that has the Bot Manager 1.1 ruleset enabled and action set to CAPTCHA for the rules - Bot100100 (Malicious bots detected by threat intelligence) and Bot100200 (Malicious bots that have falsified their identity). Behind this Azure Front Door, a web application is running and is actively protected by the WAF. We use two PowerShell snippets—one sending a known crawler User-Agent, the other spoofing a high-risk IP via X-Forwarded-For—to trigger the CAPTCHA rule. You can use Postman, Visual studio, or any other HTTP client to send these requests; this example uses PowerShell. From the results we observe a 403 Forbidden status code in both cases, indicating that WAF issued the CAPTCHA challenge and then blocked the request because no valid token was returned. In the Front Door WAF diagnostic logs, we can view the requests: This confirms that the Bot Manager rule correctly triggered the CAPTCHA action and enforced a block since the client could not complete the interactive challenge. CAPTCHA in custom rules For custom rules, you define exactly when the CAPTCHA challenge appears by creating a match-type or rate limit rule with action set to CAPTCHA. In the custom rule’s Policy Settings, you can also configure the CAPTCHA cookie lifetime - anywhere from 5 to 1,440 minutes - so that users remain validated for the duration you choose. To demonstrate the CAPTCHA challenge in action, we set up a simple scenario using Azure Front Door with a WAF policy with our custom rule created above. Behind the Front Door endpoint, a demo web application is running. The rule inspects the RequestUri and issues a CAPTCHA challenge when the URI contains /ftp. In Policy Settings, we set the CAPTCHA cookie validity to 5 minutes. In our browser, we navigate to our web application and click on the link that leads to the /ftp path. The browser briefly displays the CAPTCHA form, confirming that the challenge is active. We are presented with the CAPTCHA challenge page, select the puzzle option and proceed to solve it: After solving the puzzle, the afd_azwaf_captcha cookie appears under Response Headers. The same cookie will be sent with each subsequent request, preventing repeated challenges within the cookie lifetime and ensuring smooth navigation. The Front Door WAF logs provide detailed insights into CAPTCHA challenge requests, showing the issued, passed challenges as well as active challenges: Conclusion Malicious bots continue to threaten web applications with automated account creation, credential abuse, and data scraping. Azure Front Door WAF’s CAPTCHA challenge delivers an interactive verification step that stops sophisticated bots at the edge, complementing Bot Manager and JavaScript challenge protections. By issuing puzzles or audio challenges only on high-risk requests and tracking outcomes through built-in metrics and logs, CAPTCHA ensures genuine users navigate your site without interruption while blocking automated attacks. Together, these features provide a powerful, adaptive defense against evolving bot threats, helping organizations maintain application integrity and deliver a seamless experience for real users. References Introduction to Azure Web Application Firewall | Microsoft Learn Public Preview of Azure WAF CAPTCHA Challenge for Azure Front Door | Microsoft Community Hub Azure Front Door Web Application Firewall CAPTCHA (preview) | Microsoft Learn Web Application Firewall (WAF) on Azure Front Door | Microsoft Learn Web application firewall custom rule for Azure Front Door | Microsoft Learn
Can only remote into azure vm from DC
Hi all, I have set up a site to site connection from on prem to azure and I can remote in via the main dc on prem but not any other server or ping from any other server to the azure. Why can I only remote into the azure VM from the server that has Routing and remote access? Any ideas on how I can fix this?Monitoring web application traffic for configuring rate limit on Azure Front Door WAF
Introduction Azure Web Application Firewall (WAF) is a cloud-native service that actively protects web applications from common vulnerabilities and exploits. It also supports custom rules that allow fine-grained control over traffic. Among these custom rules is the rate-limiting feature available in both Azure Application Gateway and Azure Front Door. Rate limiting helps mitigate denial-of-service (DoS) attacks, prevents abuse from misconfigured clients sending excessive requests, and controls traffic from specific geographies. By limiting requests per client in a set time window, WAF keeps your app available and responsive even under heavy load. While rate limiting is a powerful tool for safeguarding web applications, some users struggle with configuring appropriate thresholds and durations. These two values often require tuning based on actual traffic patterns. Without proper planning or visibility into real traffic patterns, rate limit settings often end up being: Too strict – Blocking legitimate users and degrading user experience. Too lenient – Failing to stop abusive or malicious traffic. This blog is the first in a two-part series designed to help users configure rate limiting in Azure Web Application Firewall (WAF). In this first part, we focus on Azure Front Door WAF and demonstrate how to use diagnostic logs to make informed, data-driven decisions about rate limit thresholds and durations. By analyzing real traffic patterns, you can configure rate limits that strike the right balance between security and usability, protecting your application without disrupting legitimate users. Understanding rate limiting in Azure Front Door WAF At its core, rate limiting is a mechanism that restricts the number of requests a client can make to a web application within a specified period. This helps prevent issues like brute-force login attacks, automated bots scraping data, or sudden traffic spikes. Azure Front Door WAF applies rate limiting through custom rules that monitor incoming requests according to specific match conditions. Key characteristics of rate limiting in Azure Front Door WAF include: Duration: Can be set to 1 or 5 minutes. Threshold: Number of requests allowed in the time window. Customizability match conditions: You can match based on country (geolocation), IP address (remote address or socket address) request URI, HTTP method, and more. Action: What to do when the threshold is exceeded e.g., deny, log, redirect, JS Challenge (preview), CAPTCHA (preview). Below is an example of a rate limit rule configured in Azure Front Door WAF: Using diagnostic logs to configure WAF rate limiting To configure effective rate limiting policies in Azure Front Door WAF, it is important to understand how users are accessing your application. Diagnostic logs from Azure Front Door provide this visibility. In this section, we’ll walk through: Enabling diagnostic logs Querying traffic patterns with KQL Using insights to define smart thresholds and durations Enable diagnostic logs In Azure Front Door: Go to your Front Door profile. Under Monitoring, select Diagnostic settings. Click + Add diagnostic setting. Add a new setting to capture: FrontDoor Access Log – request level data. FrontDoor WebApplicationFirewall Log – WAF rule matches. Send logs to: Log Analytics workspace (recommended for querying), Storage account, or Event Hub. Save the settings. When configuring rate limit rules in Azure Front Door WAF, you can choose either a 1-minute or 5-minute time window. While both options are supported, using a 5-minute window with a higher threshold can improve detection accuracy by reducing false positives. Rate limiting is applied per socket IP - the source IP as seen by Azure Front Door. If there's another CDN or proxy in front of Front Door, this IP may not represent the original client, which can affect how rate limits are enforced. Please refer to Web application firewall rate limiting for Azure Front Door | Microsoft Learn. Analyze traffic behavior with KQL With diagnostic logs flowing into your log analytics workspace, you can begin to understand actual request volumes, IP behavior, and trends across time. These insights form the basis for defining effective rate limits. Query 1: Average requests per IP (5-minute intervals) This first query provides the average number of requests each client IP sends over 5-minute windows. It helps establish a baseline of expected activity per user. Understanding the average request rate helps you distinguish between normal and abnormal behavior. It’s your starting point for setting a rate limit that won’t block legitimate users. AzureDiagnostics | where Category == "FrontDoorAccessLog" | summarize RequestsPerIP = count() by clientIp_s, bin(TimeGenerated, 5m) | summarize AvgRequestsPerIP = avg(RequestsPerIP) by bin(TimeGenerated, 5m) | order by TimeGenerated asc Usage: Set your initial rate limit slightly above the observed average to allow for minor bursts while still preventing abuse. The screenshot below shows the average number of requests per IP in 5-minute intervals from our Azure Front Door demo environment within a 7-day period. Most intervals fall between 1 to 5 requests per IP, indicating normal user behavior. However, there are occasional spikes, such as 15.5 requests at 4:10 PM and a significant burst of 459 requests at 4:15 AM. This highlights the importance of using real data to set thresholds. While a baseline of 20–30 requests per 5 minutes would cover typical traffic, it would still catch outlier spikes like these that may indicate abuse or automation. Query 2: Max requests seen from a client IP (5-minute window) This query surfaces the maximum number of requests observed from any individual IP address in a single 5-minute time window. This helps you understand peak load behavior, which could be from a legitimate spike or a potential abuse/bot. AzureDiagnostics | where Category == "FrontDoorAccessLog" | summarize RequestsPerIP = count() by clientIp_s, bin(TimeGenerated, 5m) | summarize MaxRequestsPerIP = max(RequestsPerIP) by clientIp_s | order by MaxRequestsPerIP desc Usage: Use this to define an upper threshold for rate limiting. To avoid overfitting outliers, consider setting your limit near the 95th percentile of these max values. The screenshot below shows the results of the KQL query executed in my demo environment using Azure Front Door diagnostic logs within a 7-day period. As observed, the most active IP (35.X.X.X) recorded a peak of 459 requests within a 5-minute window, which is significantly higher than the rest. The second highest IP peaked at 106 requests, and most of the client IPs fell well below 30 requests per 5 minutes. This distribution highlights an important insight: while most users exhibit moderate request behavior, a few outliers can generate large bursts. These outliers could be misconfigured clients, aggressive bots, or potential abuse cases. When configuring rate limits, it’s advisable to base your threshold not on the absolute maximum (459), but rather on a statistical percentile such as the 90th or 95th percentile. In this case, a reasonable threshold might be around 120–150 requests per 5 minutes, allowing headroom for legitimate high-traffic users while still blocking abnormal spikes. Query 3: Most active IP per country (Geo-aware limit tuning) This query identifies the top-requesting IP address per country for each 5-minute window. Seeing regional traffic patterns allows you to detect suspicious activity from specific geographies or apply geo-based rate limits. Azure Front Door: AzureDiagnostics | where Category == "FrontDoorAccessLog" | summarize RequestCount = count() by bin(TimeGenerated, 5m), clientCountry_s, clientIp_s | summarize arg_max(RequestCount, clientIp_s) by TimeGenerated, clientCountry_s | project TimeGenerated, clientCountry_s, clientIp_s, RequestCount | order by TimeGenerated asc, clientCountry_s asc Usage: Use this to justify stricter thresholds for high-traffic countries or create region-specific custom WAF rules. The screenshot below shows the output of the geo-based query, which identifies the most active IP address per country in 5-minute intervals. As observed, some IPs consistently generate higher request volumes than others, indicating regional traffic concentration or potential anomalies. This pattern can help inform geo-specific rate limiting strategies, where regions with higher activity may warrant stricter thresholds or additional monitoring to mitigate localized abuse without impacting global user experience. Query 4: Request trends per URI segment This query breaks down requests by the first segment of the URI path (e.g., /api, /assets). It helps identify which parts of your app are most accessed. Azure Front Door: AzureDiagnostics | where Category == "FrontDoorAccessLog" | extend Path = tostring(parse_url(requestUri_s).Path) | extend FirstSegment = extract("^/([^/]+)", 0, Path) | summarize RequestCount = count() by FirstSegment, bin(TimeGenerated, 5m) | order by TimeGenerated asc, RequestCount desc Usage: Endpoints such as /login or /register are often targets for abuse. Segment-level analysis helps you target rate limits to specific parts of your app. The screenshot below shows the request distribution across the first URI segment (or resource) in 5-minute intervals. From the data, it’s clear that certain endpoints such as those serving static files (e.g., /styles.css) or known paths like /favicon.ico have consistent but low traffic. However, there are sudden spikes, such as 27 requests to /styles.css and 56 requests to /checkout.html, which could indicate automation, scraping, or testing behavior. Tracking usage by URI segment helps you identify which parts of your app are under heavy or suspicious load. You can use this insight to apply URI-specific rate limiting rules, especially for sensitive or high-traffic paths (e.g., /checkout, /login, /debug). This minimizes the risk of abuse without throttling static content or safe endpoints. Query 5: Average requests per full URI This query calculates the average number of requests per full URI across all 5-minute intervals. It helps identify high-traffic endpoints. Endpoints with consistently high traffic may need dedicated rate limits. Azure Front Door: AzureDiagnostics | where Category == "FrontDoorAccessLog" | summarize RequestsPerUri = count() by requestUri_s, bin(TimeGenerated, 5m) | summarize AvgRequestsPerUri = avg(RequestsPerUri) by requestUri_s | order by AvgRequestsPerUri desc Usage: Use this to create path-specific rules; for example, /login may need a stricter threshold than /homepage. The screenshot below shows the results of the query, highlighting which full URIs receive the highest average number of requests over 5-minute intervals. The results show frequent access to specific assets (e.g., /favicon.ico, /styles.css), REST API endpoints, and one suspicious XSS injection attempt with unusually high traffic. This insight helps identify abuse patterns, automated scans, or popular resources, guiding you to apply rate limits more precisely either globally or per path to protect critical or vulnerable endpoints. Guidance and Considerations The KQL queries and thresholds shared in this blog are intended as guidance based on common patterns and demo environments. Traffic behavior varies across applications, and you should validate results against your own environment and adjust thresholds accordingly. Always test custom rules in Detection mode before enforcing them in Prevention mode to avoid disrupting legitimate traffic. It’s also important to consider the scalability of the application or backend service behind Azure Front Door. Rate limiting controls traffic, but if your app runs on a single instance or doesn’t scale well, it may still fail under load. As a best practice, ensure your services can auto scale or handle spikes gracefully in tandem with WAF rate limiting rules. Conclusion Configuring effective rate limiting in Azure Front Door WAF is not just about setting arbitrary thresholds. It requires understanding how your application is accessed and where traffic patterns indicate potential abuse or anomalies. By leveraging diagnostic logs and analyzing real-world traffic with KQL, you can create rate limit rules that are both protective and practical. This data-driven approach helps you to reduce noise, prevent misuse, and maintain a smooth experience for legitimate users. References What is Azure Web Application Firewall on Azure Front Door? | Microsoft Learn Web application firewall custom rule for Azure Front Door | Microsoft Learn Web application firewall rate limiting for Azure Front Door | Microsoft Learn Azure Web Application Firewall monitoring and logging | Microsoft LearnAzure Networking Portfolio Consolidation
Overview Over the past decade, Azure Networking has expanded rapidly, bringing incredible tools and capabilities to help customers build, connect, and secure their cloud infrastructure. But we've also heard strong feedback: with over 40 different products, it hasn't always been easy to navigate and find the right solution. The complexity often led to confusion, slower onboarding, and missed capabilities. That's why we're excited to introduce a more focused, streamlined, and intuitive experience across Azure.com, the Azure portal, and our documentation pivoting around four core networking scenarios: Network foundations: Network foundations provide the core connectivity for your resources, using Virtual Network, Private Link, and DNS to build the foundation for your Azure network. Try it with this link: Network foundations Hybrid connectivity: Hybrid connectivity securely connects on-premises, private, and public cloud environments, enabling seamless integration, global availability, and end-to-end visibility, presenting major opportunities as organizations advance their cloud transformation. Try it with this link: Hybrid connectivity Load balancing and content delivery: Load balancing and content delivery helps you choose the right option to ensure your applications are fast, reliable, and tailored to your business needs. Try it with this link: Load balancing and content delivery Network security: Securing your environment is just as essential as building and connecting it. The Network Security hub brings together Azure Firewall, DDoS Protection, and Web Application Firewall (WAF) to provide a centralized, unified approach to cloud protection. With unified controls, it helps you manage security more efficiently and strengthen your security posture. Try it with this link: Network security This new structure makes it easier to discover the right networking services and get started with just a few clicks so you can focus more on building, and less on searching. What you’ll notice: Clearer starting points: Azure Networking is now organized around four core scenarios and twelve essential services, reflecting the most common customer needs. Additional services are presented within the context of these scenarios, helping you stay focused and find the right solution without feeling overwhelmed. Simplified choices: We’ve merged overlapping or closely related services to reduce redundancy. That means fewer, more meaningful options that are easier to evaluate and act on. Sunsetting outdated services: To reduce clutter and improve clarity, we’re sunsetting underused offerings such as white-label CDN services and China CDN. These capabilities have been rolled into newer, more robust services, so you can focus on what’s current and supported. What this means for you Faster decision-making: With clearer guidance and fewer overlapping products, it's easier to discover what you need and move forward confidently. More productive sales conversations: With this simplified approach, you’ll get more focused recommendations and less confusion among sellers. Better product experience: This update makes the Azure Networking portfolio more cohesive and consistent, helping you get started quickly, stay aligned with best practices, and unlock more value from day one. The portfolio consolidation initiative is a strategic effort to simplify and enhance the Azure Networking portfolio, ensuring better alignment with customer needs and industry best practices. By focusing on top-line services, combining related products, and retiring outdated offerings, Azure Networking aims to provide a more cohesive and efficient product experience. Azure.com Before: Our original Solution page on Azure.com was disorganized and static, displaying a small portion of services in no discernable order. After: The revised solution page is now dynamic, allowing customers to click deeper into each networking and network security category, displaying the top line services, simplifying the customer experience. Azure Portal Before: With over 40 networking services available, we know it can feel overwhelming to figure out what’s right for you and where to get started. After: To make it easier, we've introduced four streamlined networking hubs each built around a specific scenario to help you quickly identify the services that match your needs. Each offers an overview to set the stage, key services to help you get started, guidance to support decision-making, and a streamlined left-hand navigation for easy access to all services and features. Documentation For documentation, we looked at our current assets as well as created new assets that aligned with the changes in the portal experience. Like Azure.com, we found the old experiences were disorganized and not well aligned. We updated our assets to focus on our top-line networking services, and to call out the pillars. Our belief is these changes will allow our customers to more easily find the relevant and important information they need for their Azure infrastructure. Azure Network Hub Before the updates, we had a hub page organized around different categories and not well laid out. In the updated hub page, we provided relevant links for top-line services within all of the Azure networking scenarios, as well as a section linking to each scenario's hub page. Scenario Hub pages We added scenario hub pages for each of the scenarios. This provides our customers with a central hub for information about the top-line services for each scenario and how to get started. Also, we included common scenarios and use cases for each scenario, along with references for deeper learning across the Azure Architecture Center, Well Architected Framework, and Cloud Adoption Framework libraries. Scenario Overview articles We created new overview articles for each scenario. These articles were designed to provide customers with an introduction to the services included in each scenario, guidance on choosing the right solutions, and an introduction to the new portal experience. Here's the Load balancing and content delivery overview: Documentation links Azure Networking hub page: Azure networking documentation | Microsoft Learn Scenario Hub pages: Azure load balancing and content delivery | Microsoft Learn Azure network foundation documentation | Microsoft Learn Azure hybrid connectivity documentation | Microsoft Learn Azure network security documentation | Microsoft Learn Scenario Overview pages What is load balancing and content delivery? | Microsoft Learn Azure Network Foundation Services Overview | Microsoft Learn What is hybrid connectivity? | Microsoft Learn What is Azure network security? | Microsoft Lea Improving user experience is a journey and in coming months we plan to do more on this. Watch out for more blogs over the next few months for further improvements.Azure Front Door Protection against CVE-2025-8671 (MadeYouReset)
A new HTTP/2 vulnerability, CVE-2025-8671 (MadeYouReset), was recently disclosed on August 13, 2025. This attack leverages carefully crafted protocol frames to force servers into repeatedly resetting streams on a single connection, which can lead to high resource consumption and denial of service (DoS) in extreme cases. MadeYouReset and Rapid Reset (CVE-2023-44487) are two similar attack patterns exploiting HTTP/2 steam resets feature leading to resource exhaustion. Stronger Defense with Azure Front Door If you are using Azure Front Door, you are already protected against MadeYouReset vulnerability. Two years ago in 2023, when addressing the Rapid Reset (CVE-2023-44487) attack, our engineering team implemented a comprehensive mitigation for these streams reset types of attacks. Rather than limiting only client-initiated resets, we introduced stronger safeguards to account for all kinds of stream cancellation regardless of the reason to protect against different flavors of rapid reset attacks. Customer Impact These safeguards are already active in Azure Front Door. No customer action is required. Azure services remain secure and resilient against this new class of HTTP/2 protocol attacks.
