Azure Front Door WAF custom rules inconsistently applied - IP whitelist bypassed intermittently despite correct configuration

Problem Summary:

We have configured custom IP whitelist rules in our Azure Front Door WAF policy, but they are being applied inconsistently. Access to our domain works intermittently from the same whitelisted IP address - sometimes returning HTTP 200 (success), other times HTTP 403 (forbidden) - even when testing from the exact same source IP within seconds.

Environment:

• Service: Azure Front Door with WAF Policy
• WAF Policy: FSCwafpolicy (Front Door WAF policy)
• Policy Mode: Prevention
• Domain: [PII]
• Client IP: PII

Configuration Details:

We've tested multiple custom rule configurations:

1. Allowlist approach - Rule with "Does contain" + Allow action
   • Match variable: RemoteAddr
   • Operation: Does contain
     • IPs: IP, IP, IP, IP
   • Action: Allow traffic
     1. Denylist approach - Rule with "Does NOT contain" + Deny action

                 - Match variable: SocketAddr
        

        • Operation: Does NOT contain
          • Same IPs as above
        • Action: Deny traffic

                          1. **Dual-variable approach** - Two separate rules checking both RemoteAddr and SocketAddr
                      
                          
                          1. **IP ranges** - Changed from specific IPs to /24 CIDR ranges (e.g., IP/24)
                      ```**Observed Behavior:**
          
          

Testing from IP PII shows completely random results:

curl test 1: HTTP/2 200 ✓
curl test 2: HTTP/2 403 ✗
curl test 3: HTTP/2 403 ✗
curl test 4: HTTP/2 200 ✓
curl test 5: HTTP/2 403 ✗

Each response has a different x-azure-ref header, indicating requests are hitting different Azure Front Door edge nodes:

• x-azure-ref: PII... → HTTP 403
• x-azure-ref: PII... → HTTP 200

Critical Finding:

Even after disabling ALL custom rules and confirming no managed rules are enabled, we continue to experience intermittent 403 blocks from our IP address. This suggests the issue is not with our rule configuration, but rather:

• A default WAF policy behavior in Prevention mode
• Inconsistent rule propagation across Azure's global edge network
• Edge node caching issues
• Or another security layer interfering

Browsers: Chrome, Firefox, and Edge are mostly blocked (403), with very rare successful access curl: Shows 60-70% failure rate (403) from the same IP Incognito mode: Consistently blocked

Troubleshooting Steps Completed:

✓ Verified source IP hasn't changed (PII) ✓ Confirmed WAF policy is in Prevention mode ✓ Tested both RemoteAddr and SocketAddr match variables ✓ Tried exact IPs and /24 CIDR ranges ✓ Purged Front Door cache multiple times ✓ Waited 30+ minutes for global propagation between changes ✓ Tested different rule priorities (1, 2, 10) ✓ Tested with various User-Agent headers ✓ Disabled all custom rules - issue persists ✓ Confirmed no Managed Rules are active ✓ Verified WAF policy association with Front Door

Questions:

1. Why are WAF custom rules not applied consistently across all Front Door edge nodes?
2. What is the default blocking behavior when a WAF policy is in Prevention mode with no active rules?
3. Is there a recommended match variable (RemoteAddr vs SocketAddr) for IP whitelisting behind Azure Front Door?
4. How long should we expect WAF rule changes to propagate globally?
5. Are there hidden/default security policies that could cause blocking even when all custom and managed rules are disabled?

Expected vs Actual:

Expected: Consistent HTTP 200 responses from whitelisted IP PII across all edge nodes and browsers

Actual: Random 403/200 responses from the same IP, with different behavior across Azure edge nodes

Sample Output:

$ curl -4 ifconfig.me
PII

$ curl -I https://www.dev.fishertms.com
HTTP/2 403
cache-control: no-store
x-azure-ref: ...5bbn0000002y000000000039w3
x-cache: CONFIG_NOCACHE

$ curl -I https://www.dev.fishertms.com (1 second later)
HTTP/2 200
cache-control: public, must-revalidate, max-age=30
x-azure-ref: ...ntw0000000rz000000000p4k5
x-cache: CONFIG_NOCACHE

Is this a known issue with Front Door WAF? What is the recommended approach for reliable IP whitelisting that works consistently across all edge locations?