Firewalls, pg_hba.conf, and SSL
The reference for gates 1 and 2 - what to allowlist where, how pg_hba.conf decides, and how to keep the SSL settings on both ends consistent. Applies to every connectivity method.
The reference for gates 1 and 2: what to allowlist where, how pg_hba.conf decides, and how to keep the SSL settings on both ends consistent. Applies to every connectivity method.
One connection, two allowlists
| Layer | What it checks | Who owns it | Failure looks like |
|---|---|---|---|
| Cloud firewall / security group | Source IP + destination port | Cloud/network team | Silent timeout (connection timeout expired) |
pg_hba.conf | Source IP + database + user + SSL yes/no + auth method | Postgres admin (AWS-managed on RDS) | Fast, explicit rejection: FATAL: pg_hba.conf rejects connection ... |
This difference is diagnostic gold: a timeout means gate 1 dropped you (or the address is wrong); a pg_hba rejection means gate 1 passed and gate 2 said no. The error text tells you which team to call.
What to allowlist, by method
| Method | At the cloud firewall | In pg_hba.conf (self-managed) |
|---|---|---|
| Internet | Atlan's public egress IPs → your DB port | hostssl rules for those same IPs, your database, atlan_user |
| PrivateLink | NLB security group / target security group already inside your VPC - allow the NLB's subnets to reach the DB | Rules for the private source addresses the connection arrives from (the NLB/VPC ranges) - not Atlan's public IPs |
| Agent | Nothing inbound from Atlan; the agent's own address → DB port inside your network | Rules for the agent's internal address |
Over PrivateLink, connections arrive at your database from private addresses inside your own VPC (the NLB's addresses) - not from Atlan's public IPs. If pg_hba.conf or a security group filters by source address, it must allow those private ranges. Support history shows repeated multi-day loops where public IPs were allowlisted but the private path was still rejected with pg_hba.conf rejects connection.
All Atlan-side values (egress IPs, Atlan's AWS account principal, private CIDR ranges) are tenant-specific and come from support - see Atlan Network Details for the one-ticket ask that covers all of them.
pg_hba.conf in practice
# First matching rule wins - order matters.
# TYPE DATABASE USER ADDRESS METHOD
hostssl analytics atlan_user 203.0.113.10/32 scram-sha-256 # Atlan, SSL required
hostssl analytics atlan_user 203.0.113.11/32 scram-sha-256
# A broad PAM catch-all AFTER the Atlan rules, so it never shadows them:
host all all 10.0.0.0/8 pam
- Put specific rules before catch-alls. Support history includes cases where the Atlan user matched a broad
pamcatch-all first, producingFATAL: PAM authentication failedfor a user that was never meant to use PAM. hostsslvshost:hostsslonly matches encrypted connections;hostmatches either. If your only rule for the Atlan user ishostssl, the Atlan connection must have SSL moderequireor stricter.- Reload after editing (
SELECT pg_reload_conf();or a service reload). Changes don't apply from the file on disk alone.
On RDS and Aurora
- You never edit
pg_hba.conf- AWS generates it from your settings. The levers you have: the parameter group (rds.force_ssl: when1, every connection must use SSL) and per-user auth (GRANT rds_iamswitches a user to IAM tokens). - Errors still mention
pg_hba.confin the text - that's normal. Read them the same way; fix them via the parameter group and user settings.
Keeping SSL consistent end to end
| Server says | Atlan connection must say | If mismatched, you'll see |
|---|---|---|
SSL required (hostssl / rds.force_ssl=1) | require, verify-ca, or verify-full | pg_hba.conf rejects connection ... SSL off or ... no encryption |
| SSL optional | require anyway (encrypt when you can) | - |
| SSL unavailable (rare, legacy on-prem) | disable | SSL negotiation errors if set to require |
Ports
| Port | Used for | Notes |
|---|---|---|
5432 | PostgreSQL default | Prefer the default wherever you can. |
Non-default (e.g. 5433+) | Multiple databases behind one PrivateLink endpoint, via NLB listener ports | Works, but every new listener port must also be opened on Atlan's side - tell support each port you add. Port-translation setups (listener port ≠ database port) have a history of connector regressions; see Special cases. |
443 outbound | Self-deployed agent → Atlan | The agent needs outbound HTTPS to your tenant URL (and, if you use a proxy, the proxy must pass it through). |
Verify before you involve anyone else
A 60-second self-check that tells you which gate is failing - run from a machine outside your network for the internet path (your laptop on home Wi-Fi works):
# Gate 1: does TCP connect at all? (instant success = open; long hang = firewall drop)
nc -vz db.example-corp.com 5432
# Gates 2+3: does PostgreSQL accept an SSL connection for this user?
psql "host=db.example-corp.com port=5432 dbname=analytics user=atlan_user sslmode=require" -c "select 1;"
If nc hangs, it's the firewall (gate 1). If psql is rejected with a pg_hba message, it's gate 2. If it prompts for a password and refuses it, it's gate 3. Include this result in any support ticket - it cuts days off the exchange.
Change management
- Atlan egress IPs and endpoint identities change rarely, with notice via support/email to tenant admins.
- Changes on your side are the bigger risk: database restarts and failovers that changed the database's underlying IP address have broken NLB target groups and peering configurations that were pinned to fixed IPs. Prefer hostname-based targets and an RDS proxy - see Special cases.
- If a connection suddenly fails and nothing changed in Atlan, work through "It worked, then broke overnight" before opening a ticket.