Network Requirements and Firewall Rules

easyCMS players ask little of your network: outbound web traffic to your easyCMS address, nothing inbound. Give your IT team this page, and most connection problems never happen.

The short version

Outbound only. No port forwarding, no static IP, no VPN. Players do not need to reach each other or your computer.
Wired beats Wi-Fi. Screens hang high, often behind metal and far from an access point. A cable removes a whole class of support tickets.
No “click to accept” Wi-Fi. A guest network with a login page stops a player for good.
Little bandwidth after day one. Content downloads once, then plays from the player’s own storage.

Test it from the device

Before blaming easyCMS, check the device can reach it:

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

If a laptop on the same network segment can reach easyCMS but the player cannot, look at what is different: VLAN, MAC filtering, or a captive portal.

For your IT team

What the player needs

Outbound HTTPS on port 443 to your easyCMS address (normally app.myeasycms.com): registration, the check-in that fetches the schedule, and all media downloads.
An outbound channel for instant updates to the same host, so “Collect Now” and scheduled commands apply within seconds. If blocked, the player keeps working on its collection interval, typically every 5 minutes; instant updates never working while normal updates work is the sign.
DNS that resolves your easyCMS address, and NTP so the device clock is correct.

Bandwidth

Check-ins are tiny; a 50 MB video downloads once per player, then plays from local storage. Plan for your content library × the number of players at rollout, then very little until content changes. On constrained links, ask us to set a download window (media fetched overnight) and a bandwidth cap per player on the profile your account shares.

Things that block players

Blocker	What to do
Captive portals	A player cannot click “accept”. Put screens on a segment with no portal, or whitelist the player’s MAC address.
Deep-inspection proxies	A proxy that re-signs HTTPS presents its own certificate, and the player refuses it. Exempt your easyCMS address from inspection (far less work), or install the proxy’s root certificate on every player.
Self-signed or expired certificates	Players reject them; LG webOS is the strictest and gives the least helpful error. Use a certificate from a public authority.
Content filters	Signage traffic can land in “streaming media” or “uncategorised”. Whitelist your easyCMS hostname explicitly.

The checklist

Outbound only. No inbound access is required.

TCP 443 to <your easyCMS address> — content, check-ins, and the persistent connection that carries instant updates.

Exempt that hostname from HTTPS inspection. The players hold a long-lived secure WebSocket to it, and a proxy that re-signs HTTPS breaks that connection while leaving ordinary traffic working.

TCP 9505 to the same host, for players that use it for that channel instead of the WebSocket. No inbound access is required either way.

TCP 443 to the player licensing service, for Android, LG webOS and Samsung Tizen screens. These re-verify their licence every 30 days; if that call is blocked the screens keep playing what they already have and stop downloading new content about a month after installation.

TCP 443 to any host serving web content we embed on the screens.

DNS resolving the easyCMS address, and NTP so the device clock is correct.

Please also apply no content filtering to that hostname, and put the screens on a segment with no captive portal.

Tip Ask us for the exact licensing hostname to whitelist and we will send it. It depends on which players you are running.

Two lines get left out most often, and both fail quietly. Drop 9505, or inspect HTTPS on that hostname, and everything works but never instantly (instant updates not working). Block the licensing call, and Android, LG webOS and Samsung Tizen screens stop taking new content about a month later, long after anyone would connect the two.