---
title: "Allowing our agent through Azure Front Door"
source: "https://ottom.io/docs/cdn/azure-front-door"
summary: "On Azure Front Door, our agent is let through with one WAF custom rule: it matches our addresses on SocketAddr and a User-Agent header that begins with our token, with the action Allow. Custom rules run before the managed rule sets, so the Bot Manager rule set does not see the requests it allows."
---

# Allowing our agent through Azure Front Door

On Azure Front Door, our agent is let through with one WAF custom rule: it matches our addresses on SocketAddr and a User-Agent header that begins with our token, with the action Allow. Custom rules run before the managed rule sets, so the Bot Manager rule set does not see the requests it allows.

## What to match

- User agent starts with `OttomAgent/`. The full string is `OttomAgent/1.0 (+https://ottom.io/agent)`, with `Mobile` added when a check walks your store at phone size.
- Source address is one of those in https://ottom.io/agent/ips.json, also listed at https://ottom.io/agent#addresses.

Match both, never the user agent alone: anyone can send our user agent, but only we send it from those addresses.

## What you need

- Permission to edit the WAF policy linked to your Front Door profile.
- The current addresses from https://ottom.io/agent/ips.json.
- Bot Manager needs Front Door Premium. On Standard, custom rules work the same way.

## Setting it up

1. **Add a custom rule to the WAF policy.** Open the WAF policy in the Azure portal, go to Custom rules and add one. Name it AllowOttomAgent, make it a match rule and give it a priority number lower than your other custom rules, such as 10.
2. **Match our addresses.** First condition: match type IP address, match variable SocketAddr, operation IP match, and each address from the file. Use SocketAddr, not RemoteAddr: RemoteAddr is usually read from the X-Forwarded-For header, which a client can set itself.
3. **And our user agent.** Add a second condition, joined with and: match variable RequestHeader, header name User-Agent, operator Begins with, and the value below.

```
OttomAgent/
```
4. **Set the action to Allow and save.** Choose Allow and save the policy. A request it allows is not evaluated by any lower priority rule, including the managed rule sets.

## Checking it works

Run a scan of your store from your Ottom dashboard. When the rule works, the report has no bot protection finding and the agent reaches your products. In the WAF logs for the profile, our requests show AllowOttomAgent as the rule that matched, with the action Allow.

## When a scan is still blocked

### Still blocked during a traffic spike

The HTTP DDoS rule set runs before custom rules, and an Allow does not bypass it. If a scan is refused while it is acting, run the scan again once traffic is normal.

### The rule never matches

Check the first condition uses SocketAddr and that the policy is linked to the Front Door endpoint that serves your store.

## Good to know

- Custom rules are evaluated in priority order, lowest number first, and before the managed rule sets.

## Azure Front Door documentation

- Custom rules for Front Door WAF: https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-custom-rules
- Front Door WAF overview and rule order: https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/afds-overview
- SocketAddr and RemoteAddr: https://learn.microsoft.com/en-us/azure/web-application-firewall/afds/waf-front-door-geo-filtering

## Questions

### Does Allow switch off the Default Rule Set for us?

Yes, for the requests it matches. Azure runs custom rules before the managed rule sets and stops at an Allow, which is why the rule matches the address and the user agent together rather than either alone.

The same rule for other providers: https://ottom.io/docs/cdn