Allowlists, firewalls & 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 Server behind a corporate firewall | Your firewall | Firewall |
| Tableau Server behind a WAF / reverse proxy / inspection device | Content rules, not just IPs | WAF |
| 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).
Tableau Cloud IP restrictions
- Tableau admin - In Tableau Cloud: Settings → Authentication → IP allowlist (naming varies slightly by release).
- Add each Atlan NAT IP as an allowed range (a single IP is the range
x.x.x.x–x.x.x.x). - Atlan User - Re-run Test Authentication.
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
POSTto/api/metadata/graphqland/relationship-service-war/graphqlfrom Atlan's NAT IPs - Allow
POST/GETto/api/*(Tableau REST API) from the same IPs - Exempt these paths from request-body content rules for those source IPs
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
- Test Authentication in Atlan - proves sign-in (REST API) works.
- 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.