---
title: "Allowing our agent through Fastly"
source: "https://ottom.io/docs/cdn/fastly"
summary: "On Fastly, our agent is let through with a Next-Gen WAF request rule that matches our addresses from a list and our user agent, with the action Allow. On a VCL service without the Next-Gen WAF, an ACL and one condition in vcl_recv do the same job, set ahead of your own bot logic."
---

# Allowing our agent through Fastly

On Fastly, our agent is let through with a Next-Gen WAF request rule that matches our addresses from a list and our user agent, with the action Allow. On a VCL service without the Next-Gen WAF, an ACL and one condition in vcl_recv do the same job, set ahead of your own bot logic.

## 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

- Access to the Next-Gen WAF workspace for the site, or permission to edit and activate the VCL service.
- The current addresses from https://ottom.io/agent/ips.json.
- For the Next-Gen WAF, a platform with lists. Fastly says the Essential platform has none, so use one condition per address there.

## Setting it up

1. **Create a list of our addresses.** In the Next-Gen WAF, go to Security, Next-Gen WAF, Lists, and create an IP list named Ottom agent. Add each address from the file. A list made at account level can be used in every workspace, one made in a workspace only there.
2. **Create a request rule.** Go to Rules and add a request rule. Add the condition IP address, Is in list, Ottom agent. Add a second condition, User agent, Like (wildcard), with the value below, and set the rule to match all conditions. There is no starts with operator; the wildcard does that.

```
OttomAgent/*
```
3. **Set the action to Allow.** Choose Allow and save. Fastly gives an allow rule precedence over a rule that blocks, so your other block rules no longer apply to our requests.
4. **On a VCL service, add an ACL and a condition.** Without the Next-Gen WAF, declare an ACL with each address from the file and test it in vcl_recv together with the user agent. Put your existing bot or block logic inside the not branch. A local variable rather than a request header holds the result, because a client can send any header it likes. Clone the active version, add the snippet, then activate.

```
acl ottom_agent {
  "203.0.113.10";
}

sub vcl_recv {
#FASTLY recv
  declare local var.ottom BOOL;
  set var.ottom = false;
  if (client.ip ~ ottom_agent && std.prefixof(req.http.User-Agent, "OttomAgent/")) {
    set var.ottom = true;
  }
  if (!var.ottom) {
    # your existing bot and block logic
  }
}
```

## 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 Next-Gen WAF, the requests show with our user agent and the rule named against them. On a VCL service, your logging endpoint shows them answered from your origin, not with a block status.

## When a scan is still blocked

### Fastly Bot Management still challenges us

Bot Management is a separate product from the Next-Gen WAF. Fastly’s documentation does not describe a dashboard exemption for one bot, so ask Fastly support how to exempt a request that your Allow rule has matched.

### The VCL condition never matches with shielding on

On a shield node, client.ip is the Fastly edge node that forwarded the request, not us. Run the condition on the edge only, where client.ip is our address.

### 203.0.113.10 is in the example

That is a documentation address, never one of ours. Replace it with each address in the file, one line each.

## Good to know

- An ACL holds literal addresses, so it has to be edited when the file changes. A list in the Next-Gen WAF is the easier one to keep current.
- A list holds up to 5,000 entries, far more than we publish.

## Fastly documentation

- Using lists in rules: https://www.fastly.com/documentation/guides/next-gen-waf/rules/using-lists-in-rules
- Defining rule conditions: https://www.fastly.com/documentation/guides/next-gen-waf/rules/defining-rule-conditions/
- About rules: https://www.fastly.com/documentation/guides/next-gen-waf/rules/about-rules/
- VCL ACL declarations: https://www.fastly.com/documentation/reference/vcl/declarations/acl/
- About Bot Management: https://www.fastly.com/documentation/guides/security/bot-management/about-bot-management/

## Questions

### Does Allow skip the attack signatures too?

Fastly’s Allow overrides block decisions for the request, so it passes our requests over every block rule. Our agent sends nothing a shopper’s browser would not, which is why we are content with that, but you can keep a rule of your own above it.

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