Firewalls and allowlists
SQL Server traffic from Atlan usually crosses several firewalls, owned by different teams. Every layer, which Atlan value belongs in each, and the mistakes that generate the most support tickets.
SQL Server traffic from Atlan usually crosses several firewalls, owned by different teams. This page lists every layer, which Atlan value belongs in each, and the mistakes that generate the most support tickets.
Do I need this?
- Yes, for direct connectivity - the whole method depends on allowlisting Atlan's egress IPs.
- Yes, still, for private links - approval opens the tunnel, but NSGs/security groups/OS firewalls behind it keep filtering.
- No, for the self-deployed runtime - nothing inbound is opened; the agent only needs outbound HTTPS (443).
Four firewall layers
| Layer | Where it lives | Who owns it | What to allow |
|---|---|---|---|
| Database service firewall | Azure SQL "Networking → Selected networks", RDS security group | Cloud/platform team | Atlan's egress IPs (direct) on your SQL port |
| Subnet / machine firewall | Azure NSG, AWS security group + NACL | Cloud/network team | Direct: Atlan's egress IPs. Private link: Atlan's private source CIDR |
| OS firewall | Windows Firewall on the SQL Server machine | DBA / server admin | Same values as the subnet layer, on the SQL port |
| Middleboxes | Corporate edge firewalls, traffic managers, load balancers in front of the database | Network/security team | Often forgotten - a middlebox that drops unknown sources produces "handshake" errors that look like TLS problems |
Allowlisting on one layer while another still blocks produces the most confusing failure mode there is: the TCP connection opens, then resets before login. From Atlan's side that surfaces as an ODBC "handshake" error - which teams then spend weeks investigating as a TLS/driver problem. If you see error code 08001, audit all four layers first. Details in troubleshooting.
Which Atlan value goes in each rule
| Connectivity method | Rule source value | Notes |
|---|---|---|
| Direct | Tenant's public egress (NAT) IPs | Per-tenant, via support ticket. Allowlist all IPs provided - traffic can rotate between them. |
| Private link | Tenant's private source CIDR | Shared during private link setup. Public NAT IPs never appear on this path. Copy the whole block. |
| Self-deployed runtime | None (your agent's own address, if you filter internally) | The agent is inside your network already. |
All values are tenant-specific - there is no public table to copy from. See Atlan Network Details for the one-ticket ask that covers all of them: public egress IPs, private source CIDR, Atlan's AWS account ID and/or Azure subscription ID for private link permissions, and a written change-notification request.
Ports
| Path | Direction | Port | Notes |
|---|---|---|---|
| Direct / private link → SQL Server | Inbound to your database | 1433 (default) | Custom and per-instance ports are supported - enter the real port in the crawler and open that port in every firewall layer. Disable dynamic ports; load balancers need a fixed port. |
| Self-deployed runtime → Atlan | Outbound from your network | 443 | HTTPS and gRPC to your Atlan tenant and its workflow service; no inbound network access is required. |
| SQL Server redirects (listener / named instance) | Inbound to your database | varies | SQL Server may redirect clients to another host/port; the firewall must allow the redirect target too. |
Per-environment and per-port rules
- Every environment needs its own rules. PRD working proves nothing about UAT/QA if they sit behind different firewalls or VNets. Multi-environment onboardings fail on exactly the environments whose firewall path was never opened.
- Every port needs its own rule. Estates with many instances often run non-default ports (1437, 2438, ...). A rule for 1433 doesn't cover them.
- Every tenant needs its own rules. Sandbox and production Atlan tenants have different egress IPs - and possibly different regions. Allowlist each tenant you connect from.
- Listener redirects need rules too. If SQL Server redirects clients to another host/port (availability group listener, named instance), the firewall must allow the redirect target - otherwise connections fail after an apparently successful start.
When Atlan's addresses change
Atlan egress addresses change rarely, but there is currently no published changelog for SQL Server egress values. A new egress range the customer didn't know about has caused a months-long intermittent outage before. Protect yourself:
- When you request your IPs, ask support to note on your account that you require change notification.
- If a connection that worked for months starts failing with no change on your side, ask support first whether the tenant's egress addresses changed - before rotating credentials or debugging TLS. See "It worked, then broke overnight".