## Firewalls, pg_hba.conf, and SSL

URL: https://docs.atlan.com/apps/connectors/database/postgresql/references/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 |

:::danger The #1 misconfiguration

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](https://docs.atlan.com/llms/governance/administration/atlan-network-details/llms.txt) 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 `pam` catch-all first, producing `FATAL: PAM authentication failed` for a user that was never meant to use PAM.
- **`hostssl` vs `host`:** `hostssl` only matches encrypted connections; `host` matches either. If your only rule for the Atlan user is `hostssl`, the Atlan connection must have SSL mode `require` or 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`: when `1`, every connection must use SSL) and per-user auth (`GRANT rds_iam` switches a user to IAM tokens).
- Errors still mention `pg_hba.conf` in 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](https://docs.atlan.com/llms/connectors/postgresql/special-cases/llms.txt). |
| `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):

```shell

# 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](https://docs.atlan.com/llms/connectors/postgresql/special-cases/llms.txt).
- If a connection suddenly fails and nothing changed in Atlan, work through ["It worked, then broke overnight"](https://docs.atlan.com/llms/connectors/postgresql/troubleshooting-postgresql-connectivity/llms.txt) before opening a ticket.

---