Ports and firewall
SiteManager needs a few network connections. If a firewall sits on the computer that runs the service, or between that computer and the displays, allow the ones below.
Connections to the service
In local mode, the default, no inbound port is needed. The service listens on 127.0.0.1 only, so only programs on the SiteManager computer can reach it. The Windows installer adds no firewall rule in local mode, and you open nothing on Linux.
Open a port only if you open SiteManager to the network. In network mode people and scripts reach the service on one port.
| Port | Protocol | Direction | Purpose |
|---|---|---|---|
| 8790 | TCP (HTTPS) | Into the SiteManager computer | The web interface, the JSON API and the command line, in network mode. Change it with the --listen option. |
In network mode the Windows installer adds a Windows Firewall rule named SiteManager that allows inbound connections to the program. It removes the rule when you go back to local mode. On Linux the package does not change your firewall. If you use ufw, for example:
sudo ufw allow 8790/tcp
Connect directly, not through a reverse proxy
SiteManager limits failed password logins per remote address: 10 failures in 5 minutes block that address for password logins. Behind a reverse proxy every user would share the proxy's address, so one person's mistakes would lock everyone out. SiteManager ignores X-Forwarded-For on purpose, because a client could forge it. Let browsers and scripts connect to the service itself.
Never put a reverse proxy in front of a service in local mode. Everyone who reached the proxy would be the administrator. SiteManager refuses the --public-url option in local mode for the same reason.
An SSH tunnel to a local-mode service
You can reach a service in local mode from another computer through an SSH tunnel. The SSH login is then the access control. The tunnel must use the same port number on both ends, for example ssh -L 8790:127.0.0.1:8790 user@wallpc, then open http://127.0.0.1:8790/. A different local port is refused. See Troubleshooting.
Connections to the displays
The SiteManager computer connects out to the displays. If a firewall sits between them, allow these:
| Port | Protocol | Direction | Purpose |
|---|---|---|---|
| 37812 | UDP (broadcast) | Out from the SiteManager computer; the displays answer | Finds displays on the local network. A broadcast reaches only the local subnet. |
| 8080 | TCP (HTTP) | Out to each display | Reads status and sends commands to each display. |
| 5502 | TCP | Out to each display | The touch stream, called NetBridge. SiteManager uses it only to tell a display that has no SiteManager interface from a host that does not answer, and for the optional touch preview in its second-client mode. |
To find displays on another subnet or a routed network, where a broadcast does not reach, use a sweep of an address range or add displays by IP address. A sweep needs only TCP 8080 (and 5502 for hosts that do not answer on 8080).
Give the displays their own network
We advise putting the displays on their own network, separate from guest or public networks, and not exposing them to the internet. SiteManager and the displays then talk to each other on a network that you manage.
Other connections, only if you use the feature
| Connection | When it is needed |
|---|---|
| HTTP to the firmware catalogue server | To browse and download firmware on the Firmware page. You can import .swu files instead. |
| SMTP, to the server you configure | Alerts by email. |
| HTTP or HTTPS, to the address you configure | Alerts by webhook. |
| UDP, TCP or TLS syslog, to the collector you configure | Alerts by syslog. |
Checking from another computer
This applies to network mode. From the computer you browse from, open https://<computer>:8790/. The browser warns about the certificate; see First start. If the page does not load at all, the port is blocked or the service is not running. See Troubleshooting.