Azure’s Application Gateway Web Application Firewall now supports inspection and enforcement for IPv6 traffic, in public preview. Before this, the WAF could sit in front of dual-stack applications but its rules only bit on IPv4. IPv6 traffic flowed through uninspected, which was a genuine gap for anyone running regulated workloads on a dual-stack frontend. The full protection stack, managed rule sets, custom rules, and diagnostics, now extends to IPv6.
The registration gotcha
There is one piece of configuration housekeeping to understand, and Microsoft’s IPv6 geo-based custom rules documentation spells it out. You only need to register the AllowAppGwWafIpv6Geo feature flag in your subscription if you want geo-based custom rules for IPv6 traffic, the kind that block or allow by country. Everything else works without registration: IPv6 inspection with managed rule sets, custom rules built on IPv6 addresses or ranges, and logging and diagnostics of IPv6 traffic.
If you do need geo-blocking, registration happens through the usual preview-features path in the portal, or with az feature register on the Microsoft.Network namespace. Plan for it early, because the platform enforces compatibility checks: you cannot associate a WAF policy containing IPv6 geo rules with a gateway that does not support IPv6 geo evaluation, and you cannot create those rules on a policy already attached to an incompatible gateway.
You need a dual-stack gateway, and probably a new one
Here is the catch that will shape rollout plans. IPv6 WAF features require a dual-stack Application Gateway on the v2 SKU, deployed in a dual-stack virtual network, with both public and private IP configurations dual-stack. IPv6-only gateways are not supported. More significantly, you cannot convert an existing IPv4-only gateway to dual-stack. Teams that want IPv6 WAF protection are looking at deploying a new gateway and migrating, not flipping a setting.
The platform blocks incompatible configurations during policy association, which prevents the confusing half-configured state but does not make migration easier.
Geo-based rules are the use case that pushed Microsoft to build this, and the pattern is familiar from the IPv4 side: allow traffic from the countries you operate in and block the rest. Applied to IPv6, it closes a loophole that security teams have been aware of for a while, since blocking a v4 range list does nothing about the same attacker arriving over v6. Address-range rules work without the feature registration, so a simple allow-list of trusted v6 prefixes can go live as soon as the gateway does.
Known gaps in the preview
A few things remain unsupported, per Microsoft’s IPv6 Application Gateway documentation: no IPv6 backend support, no IPv6 Private Link, and no IPv6 configuration in the Application Gateway Ingress Controller. A dual-stack gateway can carry up to four frontend IPs, two IPv4 and two IPv6. If your architecture terminates TLS at the gateway and forwards to IPv6 backends, that last hop still does not work.
One more thing worth flagging: the Microsoft Learn documentation is still settling. Some pages, including the IPv6 Application Gateway guide, carried older language stating that custom rules did not support IPv6 traffic, while the newer geo-based rules page documents non-geo IPv6 address rules working without registration. During a preview, documentation and behavior can drift apart, so verify the specific rule type you plan to use against your own gateway before committing to a design.
What migration actually involves
Because in-place conversion is off the table, a migration project has real steps. Provision the new gateway in a dual-stack virtual network, on a dual-stack subnet, with both public and private frontend IP configurations set to dual-stack. Attach the WAF policy, register AllowAppGwWafIpv6Geo first if you intend to use geo rules, since policy association fails on incompatible configurations otherwise. Then shift traffic, usually with a staged cut-over on your DNS or Traffic Manager layer.
Validation is well supported: WAF resource logs carry the IPv6 details you need to confirm enforcement, and Microsoft’s guidance for the feature explicitly includes validating behavior through logs and diagnostics before trusting it. Given the documentation drift mentioned above, that validation step is not optional during the preview. Test your managed rule set against IPv6 traffic that should be blocked, and test any custom rules with v6 addresses or ranges you plan to match on.
Why this matters beyond the checkbox
IPv6 adoption has been grinding upward for years, pushed along by IPv4 address exhaustion and mobile carrier networks that hand out v6 addresses by default. Web application firewalls that only inspect IPv4 created an awkward architectural fork: either route IPv6 traffic through something else or accept reduced coverage on half your traffic. Closing that gap makes dual-stack a defensible first-class posture on Azure rather than a compromise.
The conversion limitation is the real operational story. Anything that requires a new gateway deployment plus migration turns a feature announcement into a project. Teams running production dual-stack workloads should treat this as the signal to start planning the migration now, test the preview in non-production, and have the new gateway architecture ready before the GA announcement arrives, because the preview terms apply until then.