# Using tuna in a corporate network

Most often there should be no problems with this, as corporate firewalls allow outgoing connections, however there may be restrictions on connection ports that may interfere with tuna operation.

If you encounter errors when creating a tunnel, run the `tuna diagnose` command to get diagnostic information. The report will help you better understand where exactly the problem is.

```shell
Please wait, testing connectivity...

TLS connectivity:
  Google.com: ok [1.46189625s]
  Yandex.ru: ok [1.246520375s]
  tuna API: ok [1.484186875s]
DNS:
  api.tuna.am: alt-lb.tuna.am. → eu-lb.tuna.am. [147.45.149.16, 194.31.173.118]
  a.2na.am: edge-eu-a.2na.am. [2.28.136.177, 89.19.217.251]
TCP connectivity:
  tuna edge a 2.28.136.177:443: ok [41.53925ms]
  tuna edge a 89.19.217.251:443: ok [38.112708ms]
  tuna node DE node-1-de.2na.am:443: ok [52.81425ms]
  tuna node RU node-1-ru.2na.am:443: ok [34.079541ms]

```

As a rule, tuna uses port `443` to connect to nodes when creating a tunnel. If the `TCP connectivity` checks fail, contact your network administrators to resolve the issue.

## Which addresses to allow in the firewall

tuna CLI connects to the API and to nodes on port `443`. If your firewall only lets through allowed addresses, open access to:

* `api.tuna.am` and `my.tuna.am`, the API and the dashboard: the CLI calls the API on every run;
* nodes: the CLI connects to them when it brings up a tunnel;
* cells, if tunnel addresses are opened from the same network: cells receive the traffic to tunnels and [custom domains](https://tuna.am/en/docs/tunnels/guides/connect-self-domain.md).

The table lists the addresses of nodes and cells. The addresses of `api.tuna.am` and `my.tuna.am` are not in it.

The current address list in JSON: <https://api.tuna.am/v1/system/ips>

Allow every address in the list, not just the ones that resolve from your office. `api.tuna.am`, `my.tuna.am` and the cell zones are served by GeoDNS, which returns different load balancers for Russia and for other regions. The `DNS` section of the `tuna diagnose` output shows where GeoDNS sent your network: the region is given by the last name in the CNAME chain. For example, `edge-ru-a.2na.am.` means Russia, and `edge-eu-a.2na.am.` means other regions.

The addresses are currently fixed. If they change, we will try to notify you by email in advance. Either way, the current list is always available from the [API method](#ips-api), so you can check for changes yourself.

If your firewall supports FQDN-based rules, allow access by name, and you won't have to update the rules when the addresses change.

### Fetching the addresses automatically

The list is available from a public API method that requires no authorization:

```shell
curl -fsS https://api.tuna.am/v1/system/ips | jq -r '.ingress_cells[].ips[], (.nodes[].ip // empty)' | sort -u

```

The response has two arrays:

* `ingress_cells` are cells. `ips` holds the addresses that receive traffic to tunnels, and `zone` is the cell's main zone, which CNAME records of custom domains point to. Take the addresses of all cells regardless of `status`: cells in the `draining` status still receive traffic.
* `nodes` are nodes. `address` is the host and port the CLI connects to, `ip` is the node's address, and `region` is the node's country as an ISO 3166-1 alpha-2 code, such as `DE`. The `ip` and `region` fields may be missing. Without `ip`, allow access by the name from `address`.

The server refreshes the response every 5 minutes, so polling the method more often makes no sense. The method supports `ETag`: with the `If-None-Match` header it returns `304` if the list hasn't changed, which makes it convenient to check for changes on a schedule. The limit is one request per second from a single IP address; above it, the server responds with `429`. The method is described in [Swagger](https://my.tuna.am/swagger/), tag `SystemIPs`.