Microsoft announced public preview of IPv6 support for Application Gateway Web Application Firewall on October 5, 2026. The update extends managed rules, custom rules, and diagnostics to IPv6 traffic, bringing WAF inspection and enforcement to dual-stack applications. Read the Azure announcement.
This is an opportunity to examine whether a security policy behaves consistently across the application's IPv4 and IPv6 entry points. It is not enough to establish that a page loads over the new address family.
My recommendation is to build a small, explicit validation set for both paths and keep the preview's configuration requirements visible in the change record.
Separate Inspection from Geo-Rule Enrollment
The new WAF guidance requires subscription registration of AllowAppGwWafIpv6Geo for IPv6 geo-based custom rules. That registration is not required for managed-rule inspection, non-geo IPv6 custom rules, or IPv6 logging and diagnostics. When feature registration is required.
I would classify the existing policy before enabling anything. Which controls inspect requests, which match addresses, and which depend on geography? Assign an expected result to each relevant rule in the test environment.
This avoids treating enrollment in one preview capability as evidence that every policy requirement has been met. Configuration state and observed enforcement should be recorded separately.
Keep the policy owner involved when interpreting an unexpected result. The engineer deploying a gateway should not have to infer the intended business rule from a long list of conditions.
Check the Gateway Architecture First
Microsoft's IPv6 frontend guide says dual-stack connectivity requires a new Application Gateway; an existing IPv4-only gateway cannot be converted in place. It also lists IPv6-only gateways and IPv6 backend addresses as unsupported. Frontend setup and architecture limits.
For IPv6 geo rules, the WAF guidance requires an IPv6-capable dual-stack gateway, dual-stack public and private IP configurations, and association of the policy with a compatible gateway. Geo-rule requirements.
My proposed design review would draw the client-to-gateway and gateway-to-backend connections separately. Record where each address family is used and which component terminates each connection.
Do not turn a frontend announcement into an assumption about end-to-end IPv6 support. Verify the deployment model you actually intend to operate, including its listeners, routing, certificates, and backend health checks.
Use the New Feature Guidance for the Preview
As checked on October 6, 2026, the general IPv6 frontend guide still lists older WAF custom-rule restrictions. The new announcement and dedicated IPv6 geo-rule documentation describe the expanded preview support. Those pages are not fully aligned yet. General guide, new WAF guidance, and announcement.
I would retain the dated preview guidance with the design record and confirm any unclear configuration with Microsoft before relying on it. Do not describe the feature as generally available or assume every existing deployment is eligible.
If policy association fails, preserve the validation message and investigate compatibility. Removing the control simply to complete deployment would leave the original requirement unresolved.
Test the Decision, Not Just Connectivity
My proposed test set has three parts: an ordinary request that should succeed, an approved harmless test request that should trigger the intended control, and a legitimate edge case that must not be blocked.
Run the same logical cases over IPv4 and IPv6 using infrastructure you control. Record the hostname, selected address family, policy, rule, timestamp, response, and matching diagnostic evidence.
For geo-based controls, use authorized test clients with known locations and document what the service reports. Geography should be evaluated as the rule's input, not treated as proof of a person's identity or authorization.
Keep test traffic bounded and away from unrelated systems. The purpose is to verify your policy's behavior, not to generate attack traffic or stress a production application.
Make Logs Useful to the On-Call Team
I would ask the operations team to investigate one allowed and one blocked test without help from the person who configured the preview. Can they find the relevant event, explain the matched policy, and identify the request path?
Check any log queries, dashboards, or exports that assume an IPv4-shaped client address. A new traffic path is only operationally useful if the existing investigation process can represent it correctly.
Then rehearse the response to an unintended block. Record who can change the policy, how that change is reviewed, and what evidence confirms normal service afterward.
These are proposed validation steps, not results from a gateway deployment I have performed.
Practical Cloud Engineer Takeaway
Inventory the policy decisions that must work over both address families.
Distinguish geo-rule enrollment from other IPv6 WAF capabilities.
Confirm the gateway, frontend, and backend architecture.
Resolve documentation or compatibility questions before rollout.
Test allowed, blocked, and legitimate edge-case requests.
Confirm diagnostic visibility using the on-call team's workflow.
Keep a reviewed recovery procedure for unintended policy behavior.
Who Should Care?
Azure network engineers, application owners, and security operations teams evaluating dual-stack frontends protected by Application Gateway WAF.
Bottom Line
IPv6 WAF support broadens the available security controls for dual-stack applications. A good preview evaluation proves consistent policy decisions and usable diagnostics on both paths while respecting the documented deployment limits.
Sources
Stay radical, stay curious, and keep pushing the boundaries of what is possible in the cloud.
Chriz
Beyond Cloud with Chriz
Comments