Firewall Configuration
WATCHOUT nodes communicate over UDP and TCP for discovery, playback sync, media distribution, time sync, and external control. If a firewall blocks one of these paths, nodes may fail to discover each other, playback may lose sync, or media may not transfer.
WATCHOUT configures the Windows Defender Firewall automatically: the Process Manager service sets up the rules on every node, every time it starts. This page documents the ports and programs it opens so you can configure any other firewall on the network.
How WATCHOUT configures the firewall
The node management service creates the Windows Defender Firewall rules — not the installer. It runs a self-heal pass on every startup: it reads the firewall registry, checks that every rule for this install is present, and adds only the missing ones. Rules it did not create are never touched. Because the check runs at every startup, a rule removed by hand is re-added the next time the node starts.
WATCHOUT creates two kinds of inbound allow rules:
- Three port rules — UDP 123 (NTP time sync) and UDP 3011 / 3012 (multicast discovery).
- One program rule per WATCHOUT executable — these allow inbound traffic for each service regardless of port, which covers every TCP service port and any dynamically assigned port. There is a program rule for each executable in the install folder (Process Manager, Director, Runner, Asset Manager, Operative, Visual Renderer, Audio Renderer, PTP, mDNS Responder, NMOS Controller, the bridges, and others).
Outbound traffic is unrestricted by default on Windows.
WATCHOUT only manages the Windows Defender Firewall. If you run a third-party firewall, or turn Windows Defender Firewall off, open the ports and programs below by hand — see Manual configuration for restricted environments.
Ports WATCHOUT uses
This table is a reference for planning and diagnostics. Only the first three rows are opened as dedicated port rules — every other port is reached through a program rule, not a port rule.
| Port | Protocol | Purpose |
|---|---|---|
| 123 | UDP | NTP time synchronization |
| 3011 | UDP | Multicast discovery query |
| 3012 | UDP | Multicast discovery — nodes announce and respond on multicast group 239.2.2.2 |
| 3017 | TCP | Node management — status, remote file access, software updates |
| 3018 | TCP | Runner — playback state from the Director |
| 3019 | TCP | External control API (HTTP) |
| 3020 | TCP | Internal control between services on the same node |
| 3021 | TCP | Director — show data and Runner coordination |
| 3022 | TCP | Logging service |
| 3023 | TCP | Asset Manager — media distribution |
| 3024 | TCP | WATCHPAX Config |
| 3025 | TCP | NMOS Controller |
| 8000 | UDP | OSC |
| 8001 | TCP | OSC over TCP |
When the matching input protocol is enabled, the Operative service also listens for Art-Net on UDP 6454 and PosiStageNet on UDP 56565 (multicast). Both are covered by the Operative program rule.
Manual configuration for restricted environments
In environments with Group Policy-managed firewalls, the rules WATCHOUT creates may be blocked or removed. The self-heal pass re-adds removed rules on the next node startup, but it cannot add rules where Group Policy blocks rule creation entirely. In that case, create them by hand:
- Add the three port rules — inbound allow for UDP 123, 3011, and 3012.
- Add a program rule for each WATCHOUT executable in the install folder. This covers every service port and any dynamic port.
- Allow UDP multicast on the discovery group 239.2.2.2. Some enterprise firewalls strip multicast by default.
- Allow ICMP if your network uses ping for diagnostics (optional).
Partial firewall openings cause hard-to-diagnose problems. Blocking only discovery (UDP 3012) stops nodes finding each other while every other service still works in isolation — nodes look connected but cannot coordinate. Verify all paths when troubleshooting.
Other transports
If your installation uses video-over-IP or networked audio, more considerations apply:
- NDI® — discovery uses mDNS, and streams use dynamically assigned ports. The mDNS Responder, Visual Renderer, and Runner program rules cover NDI. See NDI on the Network.
- Dante — uses its own ports managed by the Dante stack. The PTP and mDNS Responder program rules cover Dante clock sync and discovery. See Dante Audio.
- ST 2110 — flows over the Deltacast board's own network ports, separate from the node's NIC. Allow PTP and the sender multicast groups on the ST 2110 network. Keep NMOS control traffic on a separate controller network. See Setting Up ST 2110.
Switch and infrastructure
Discovery uses UDP multicast on group 239.2.2.2. Nodes then connect using the IP address each node announces. Any infrastructure that blocks that multicast, or rewrites node IP addresses, breaks discovery or the connections that follow:
- Managed switches often prune or block multicast. Enable IGMP snooping (or multicast forwarding) for 239.2.2.2.
- VLANs that separate nodes break discovery. Keep nodes that must see each other in the same multicast domain.
- VPNs often do not forward multicast. Nodes across a VPN segment may not discover each other.
- NAT between nodes breaks the direct IP connections that follow discovery. Give all nodes direct IP reachability to each other.
Related
- Network Overview — the communication architecture and discovery group
- Time Synchronization — NTP on UDP 123
- NDI on the Network — NDI network requirements
- Network Issues — diagnosing blocked discovery and connections
NDI® is a registered trademark of Vizrt NDI AB.