> ## Documentation Index
> Fetch the complete documentation index at: https://docs.iotmanager.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Firewall Rules

> What network access a device needs

IoT Manager devices only ever make **outbound** connections. There is nothing to open inbound, no port forwarding to configure, and no static/public IP required — the dashboard reaches your devices through a reverse tunnel that the device itself initiates.

## What the device connects to

| Destination               | Port        | Purpose                                                                  |
| ------------------------- | ----------- | ------------------------------------------------------------------------ |
| `api.iotmanager.dev`      | 443 (HTTPS) | Device registration, telemetry reporting, uninstall callback             |
| `*.tunnel.iotmanager.dev` | 443 (WSS)   | Reverse tunnel — terminal, file transfer, container control, public URLs |

Both connections are standard HTTPS/WebSocket-over-TLS on port 443 — if your network already allows normal outbound web browsing, it allows this too. No unusual ports, no custom protocols.

## Behind a restrictive outbound firewall

If your network only allows specific outbound destinations (common in industrial/locked-down environments), allowlist:

```
api.iotmanager.dev:443
*.tunnel.iotmanager.dev:443
```

<Note>
  The exact subdomain under `tunnel.iotmanager.dev` is assigned per-device and can vary — allowlisting the wildcard is the reliable option. If your firewall doesn't support wildcard TLS/SNI-based rules, allowlist by destination port 443 to any host under `tunnel.iotmanager.dev` instead of trying to pin an exact hostname.
</Note>

## What's NOT needed

* No inbound ports — the device is never listening for connections from the internet.
* No VPN.
* No static/public IP address. Devices behind NAT, CGNAT, or on a private LAN with no port forwarding work identically to devices with a public IP.
* No SSH daemon exposed publicly — the agent's built-in SSH server only ever accepts the reverse tunnel connection it initiated itself; nothing needs to reach it from outside.

## Local/offline access

If a device is fully air-gapped (no internet at all), the reverse tunnel obviously can't connect — but the device's local web UI is still reachable directly on your LAN. See [Offline Use](/offline-use).