# Allowlist sanda's address

> Every sync reaches your systems from one fixed IP address. Allow it through your firewall before you connect a database or a locked-down store.

Every sync reaches your systems from one fixed address:

```text title="sanda's sync address"
203.76.224.154
```

If the system you are connecting sits behind a firewall, a cloud security group or an IP allowlist, add this address before you connect. Otherwise sanda cannot get through, and the connection fails at the first step.

The address is the same for every workspace and every connection. sanda only ever reads from your systems, and it connects from this address for setup checks as well as for syncs.

## Where to find it in the console

You can copy the address from three places in the console, so you never need to leave the connection flow to find it.

- **The setup guide** beside every connector's form. It shows the address in a callout, headed **Allowlist sanda before connecting** for sources that dial into your own infrastructure and **Behind a firewall or IP allowlist?** for the rest.
- **The list of connections.** A line under the table reads **Connecting something behind a firewall? sanda syncs from one fixed address: allowlist** followed by the address.
- **A connection's Settings tab.** The **Network** panel, described as "For sources behind a firewall, VPC rule or IP allowlist", shows it too.

## Which sources need it

You need to allow the address wherever the source lets you restrict who can connect.

| Source | What to allow |
|---|---|
| PostgreSQL | The address, on your database port (5432 by default). Set it in your cloud provider's network rules, in `pg_hba.conf`, or both |
| MySQL and MariaDB | The address, on your database port (3306 by default), in your provider's network rules or security group |
| SQL Server | The address, on port 1433 or your instance's port. On Azure SQL, add it under the server's networking rules |
| S3 | Only if the bucket policy restricts access by IP range. Add the address to that range |
| SaaS systems such as Xero or Stripe | Usually nothing. Some sit behind gateways that restrict by IP, in which case add the address there |

Database connectors show the prominent version of the callout because sanda dials straight into your infrastructure. For the exact steps to create a read-only login and open the port, follow the setup guide beside the connector's form, or the page for your connector in the [catalogue](https://docs.sanda-os.com.au/connectors).

## Do it in this order

:::steps
1. **Allow the address first.** Add it to the firewall or security group that protects the database.
2. **Add the connection.** Fill in the form and press **Read schema**. See [Add a connection](https://docs.sanda-os.com.au/connections/add-a-connection).
3. **Check the result.** If sanda cannot get through, the step fails with a message about the network. See [Troubleshoot connections](https://docs.sanda-os.com.au/connections/troubleshooting#the-connection-is-refused-or-times-out).
:::

## Hosts sanda can reach

sanda connects from the internet, so a database host has to be reachable from the internet. Before it tries, sanda checks the host you entered and refuses the ones that can never work:

- `localhost` and other addresses that mean "this computer".
- Private network addresses, such as `10.x.x.x`, `172.16.x.x` to `172.31.x.x` and `192.168.x.x`.
- Names with no domain, and names ending in `.local`, `.internal`, `.lan` or another suffix that only resolves inside a private network.
- A name that does not exist on the public internet, or one that resolves to a private address.

If your database is only reachable inside your network, give it a public address and lock that address down to sanda's, or route it through something that is reachable from outside. Some database connectors also offer an SSH tunnel option under **Advanced settings**. The tunnel host is held to the same rule: it has to be reachable from the internet, and it needs sanda's address allowed.

## Database encryption

Your sign-in details reach sanda's managed sync over TLS, and sanda never writes them to its own database.

For the connection from sanda to your database, the setup guides recommend the strongest option your server supports:

- **PostgreSQL:** keep SSL on `require` unless the server cannot do TLS at all.
- **MySQL:** prefer SSL where the server supports it.
- **SQL Server:** leave encryption on unless the server predates it.

The SSL choices on offer come from the connector's own form, so they differ by source.

:::note
Allowing the address does not give sanda any more access than the login you create for it. Give sanda a read-only login of its own, so its access is easy to see, audit and revoke.
:::

## If the address ever changes

The console always shows the current address. If a connection that used to work starts failing with a network error, compare the address in the setup guide with the one in your firewall rules.

:::links
- [Add a connection](https://docs.sanda-os.com.au/connections/add-a-connection): The full flow, step by step.
- [Troubleshoot connections](https://docs.sanda-os.com.au/connections/troubleshooting): Network errors and what they mean.
- [Connector catalogue](https://docs.sanda-os.com.au/connectors): Every source, with its own setup notes.
:::