## Allowlists, firewalls & WAFs

URL: https://docs.atlan.com/apps/connectors/business-intelligence/tableau/references/allowlists-firewalls-and-wafs

> The three gatekeepers that can sit between Atlan and Tableau - Tableau Cloud's IP allowlist, your firewall, and WAF content rules - and how to open each.

Three different gatekeepers can sit between Atlan and Tableau. This page covers all three - because "the IP is allowlisted" does not mean "the traffic gets through".

## Do I need this?

| Situation | Gatekeeper | What to do |
|---|---|---|
| Tableau Cloud, admin enabled IP restrictions | Tableau Cloud's built-in IP allowlist | [Tableau Cloud](#tableau-cloud-ip-restrictions) |
| Tableau Server behind a corporate firewall | Your firewall | [Firewall](#your-firewall-tableau-server) |
| Tableau Server behind a WAF / reverse proxy / inspection device | Content rules, not just IPs | [WAF](#wafs-and-inspection-proxies) |
| None of the above | - | Nothing. Atlan connects without allowlisting. |

## Step 0 for all three: Get your Atlan IPs

Every path starts with your tenant's outbound **NAT IPs**. They are static, tenant-specific, and **not published** - one support ticket gets them (see [Atlan Network Details](https://docs.atlan.com/llms/governance/administration/atlan-network-details/llms.txt)).

## Tableau Cloud IP restrictions

1. *Tableau admin* - In Tableau Cloud: **Settings → Authentication → IP allowlist** (naming varies slightly by release).
2. Add each Atlan NAT IP as an allowed range (a single IP is the range `x.x.x.x`–`x.x.x.x`).
3. *Atlan User* - Re-run **Test Authentication**.

:::note Symptom if you skip this

The PAT is valid, yet sign-in is rejected or times out. If a PAT that works from your laptop fails from Atlan, an IP restriction is the first suspect.

:::

## Your firewall (Tableau Server)

Ask your network team for one inbound rule:

| Field | Value |
|---|---|
| Source | Your Atlan tenant's NAT IPs (from support - the values below are illustrative) |
| Destination | The Tableau Server host |
| Port | `443` (or your custom Tableau port) |
| Protocol | TCP (HTTPS) |
| Direction | Inbound only - Atlan never needs Tableau to connect out |

```

# ALLOW inbound HTTPS from Atlan tenant NAT IPs (examples - get real values from support)

allow tcp from 203.0.113.10, 203.0.113.11 to tableau.example-corp.com port 443
```

## WAFs and inspection proxies

A **WAF** inspects what a request *contains*, not just where it comes from. Atlan's lineage crawl sends large GraphQL `POST` requests to `/api/metadata/graphql` - which generic WAF rules can misclassify and block *even though the source IP is allowlisted*. A WAF rule can start rejecting only the connector's metadata queries after either side updates (new WAF rules, or a connector update changing the request signature); crawls then fail with an HTML block page while everything else works.

Give your WAF team this exception request:

- Allow `POST` to `/api/metadata/graphql` and `/relationship-service-war/graphql` from Atlan's NAT IPs
- Allow `POST`/`GET` to `/api/*` (Tableau REST API) from the same IPs
- Exempt these paths from request-body content rules for those source IPs

:::tip How to recognize a WAF block

The workflow log shows an HTML error page (e.g. *"The requested URL was rejected… support ID …"*) instead of a JSON error from Tableau. Tableau never returns HTML block pages - that response came from something in front of it.

:::

## Verify, whatever you changed

1. **Test Authentication** in Atlan - proves sign-in (REST API) works.
2. Run **preflight** - its Metadata API check proves the second door works too. A pass on step 1 with a fail on step 2 usually means a content rule, not an IP rule.

---