Network Requirements and Firewall Rules

What easyCMS players need from your network, outbound HTTPS, the instant-update channel, proxies, captive portals and certificates, plus how to test a connection from the device.

easyCMS players are undemanding on the network, but they are strict about a few things. Give your IT team this page and most connection problems never happen.

What the player needs

Outbound HTTPS on port 443 to your easyCMS address (normally app.myeasycms.com). This carries registration, the check-in that fetches the schedule, and all media downloads. Nothing needs to be opened inbound to the player, no port forwarding, no static IP, no VPN.

An outbound channel for instant updates to the same host. This is what makes “Collect Now” and scheduled commands apply within seconds instead of at the next check-in. If your firewall only permits standard web traffic, this channel may be blocked. The player keeps working, it simply falls back to updating on its collection interval, typically every 5 minutes. Instant updates never working, while normal updates work fine, is the signature of this being blocked.

DNS that resolves your easyCMS address, and NTP so the device clock is correct.

That is the whole list. Players do not need to reach each other, and they do not need to be on the same network as your workstation.

Bandwidth

Signage is bursty, not continuous. Check-ins are tiny. The load is media downloads: a 50 MB video downloads once per player and then plays from local storage forever. Plan for:

  • The size of your content library × the number of players, once, at rollout.
  • Very little afterwards, until you change content.

On constrained links, set a download window in the display settings profile so players fetch media overnight, and cap the bandwidth per player. Both are per-profile settings in easyCMS.

Things that block players

Captive portals. Guest Wi-Fi that shows a “click to accept” page will silently stop a player forever, it cannot click. Put screens on a network segment with no portal, or whitelist the player’s MAC address.

Deep-inspection proxies. A proxy that re-signs HTTPS presents its own certificate. Unless that certificate is installed as trusted on the device, the player refuses the connection. Either exempt your easyCMS address from inspection, or install the proxy’s root certificate on every player. Exempting is far less work.

Self-signed and expired certificates. Players reject them. Smart-TV players (LG webOS, Tizen) are the strictest and give the least helpful error. Use a certificate from a public authority.

Content filters that block by category. Signage traffic occasionally lands in “streaming media” or “uncategorised”. Whitelist your easyCMS hostname explicitly.

Wi-Fi that drops. Screens are usually mounted high, often behind metal, frequently far from an access point. Wired Ethernet removes an entire class of support tickets and is worth the cable run every time.

Testing from the device

Before blaming easyCMS, prove the device can reach it:

  1. Open the device’s own browser.
  2. Load your easyCMS address. You should get the login page, with a valid padlock.
  3. If that fails, the problem is network, DNS or certificate, and it is on your side of the connection.

On Windows and Linux you can also check from a command line on the same network segment. If a laptop on that segment can reach easyCMS but the player cannot, look at what is different: VLAN, MAC filtering, or the captive portal.

A checklist to hand to IT

Signage players need outbound HTTPS (TCP 443) to <your easyCMS address>, plus DNS and NTP. No inbound access is required. Please exempt that hostname from HTTPS inspection and content filtering, and ensure the network segment has no captive portal.

Related articles: /support/troubleshooting-offline-displays/, /support/connecting-your-first-display/, /support/player-status-window-and-logs/