Network requirements for Polaris

Connect Pods and clients to cloud services

Allow outbound HTTPS on TCP 443 from both the Pod VLAN and the client VLAN to the endpoints below. These connections support signaling, licensing, and management. When the sharing device and Pod are on the same network, their shared content does not travel through these cloud endpoints.

Allow time sync and NAT traversal

Allow the outbound UDP traffic below through your firewall and NAT policies. Clock drift over two minutes breaks TLS certificate validation.

Allow the TURN relay for restrictive networks

The TURN relay is optional and enabled per organization. Media goes through it only when no direct or STUN-assisted path can form, or when an administrator forces relayed connections. Pods and sharing clients connect to it outbound only, so nothing needs to be opened inbound. The relay is IPv4 only.

The relay port range may change as capacity is adjusted. The Mersive relay has no TLS or port 443 path. Organizations that need one should use the Cloudflare relay below.

If your organization uses the Cloudflare relay, allow these instead:

Cloudflare serves its relay from an anycast network and publishes no fixed relay port range.

Allow multicast discovery on the Pod VLAN

AirPlay and Google Cast use local discovery to find the room. Allow the multicast traffic below on the Pod VLAN. Filtering this traffic prevents native casting discovery; joining through the browser is unaffected.

Connect the client VLAN to the Pod VLAN

When Pods and client devices are on separate VLANs, allow traffic to the Pod-side ports below for casting and sharing. The WebRTC media path also requires bidirectional UDP traffic between the two VLANs.

The required production range is UDP 40000–49999. The diagnostic tool samples that range and also spot-checks UDP 32768–39999 and UDP 50000–65535 to identify partial blocks. Those additional probes are diagnostic checks, not additional production port requirements.

Review the VLAN reference design

This reference design separates client devices on VLAN 10 from Pods on VLAN 20, with a stateful firewall between them. Use the traffic flows below alongside the detailed tables above when reviewing your network rules.

Check the network from each VLAN

Use mersive_network_diag.py to check connectivity from a machine on the target network. The tool requires Python 3.7 or later and uses the standard library, with no additional packages to install. Choose the checks below for the network path you are testing.

For a deployment with separate VLANs, run the tool once from the client VLAN and once from the Pod VLAN. To check the path between them, run it from the client VLAN and specify a Pod-VLAN address with --pod-ip. Replace 10.0.2.50 in the example with the Pod address you want to test.

NAT symmetry: symmetric NAT silently breaks WebRTC even when every port appears open, because each destination sees a different external port and no direct path can be formed. The tool validates NAT type against both STUN servers and reports symmetric NAT as a critical failure.

How cross-network sharing connects →