---
title: "Polaris Network Requirements: Ports & VLANs | Mersive"
canonical: https://www.mersive.com/resources/network
description: "Review Polaris ports, protocols, cloud endpoints, and VLAN traffic flows to plan network rules and prepare for deployment."
language: en-US
publisher: Mersive Technologies
---

# Network requirements for Polaris

[Read network documentation ↗](https://documentation.mersive.com/en/mcs/network-requirements.html)

Plan your Polaris deployment with the ports, protocols, and endpoints your network team needs to review. Start with the cloud connections, check the local sharing paths, and use the reference design to assess your VLAN rules.

Outbound · cloud services

## 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.

| Port | Protocol | Endpoint | Purpose |
| --- | --- | --- | --- |
| TCP 443 | HTTPS/TLS | app.mersive.com | Portal / signaling server |
| TCP 443 | HTTPS/TLS | display.mersive.com | Mersive display app |
| TCP 443 | HTTPS/TLS | mcsapi.mersive.com | Polaris API service |
| TCP 443 | HTTPS/TLS | webrtc.mersive.com | WebRTC signaling server |
| TCP 443 | HTTPS/TLS | hosted.mender.io | Update server |
| TCP 443 | HTTPS/TLS | hosted-mender-artifacts.s3.amazonaws.com | Update artifacts (AWS S3) |
| TCP 443 | HTTPS/TLS | c271964d41749feb10da762816c952ee.r2.cloudflarestorage.com | Update artifacts (Cloudflare R2) |
| TCP 443 | HTTPS/TLS | app.launchdarkly.com | Feature flags |
| TCP 443 | HTTPS/TLS | clientstream.launchdarkly.com | Feature flag streaming |
| TCP 443 | HTTPS/TLS | events.launchdarkly.com | Feature flag events |
| TCP 443 | HTTPS/TLS | firestore.googleapis.com | Real-time state sync |
| TCP 443 | HTTPS/TLS | firebasestorage.googleapis.com | Storage & licensing info |
| TCP 443 | HTTPS/TLS | identitytoolkit.googleapis.com | Authentication (identity) |
| TCP 443 | HTTPS/TLS | securetoken.googleapis.com | Authentication (token) |

Outbound · UDP

## 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.

| Port | Protocol | Endpoint | Purpose |
| --- | --- | --- | --- |
| UDP 123 | NTP | ntp.mersive.com | Time sync (fallback: time.google.com) |
| UDP 19302 | STUN | stun.l.google.com | WebRTC NAT traversal |
| UDP 19302 | STUN | stun1.l.google.com | NAT traversal (backup) |

Outbound · TURN relay

## 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.

| Port | Protocol | Endpoint | Purpose |
| --- | --- | --- | --- |
| UDP 3478 | TURN / STUN | Mersive TURN relay (address in your organization's ICE settings in the Polaris portal) | Relay allocation and NAT discovery |
| TCP 3478 | TURN | Mersive TURN relay | Relay allocation where outbound UDP 3478 is blocked |
| UDP 49152–49751 | TURN relay | Mersive TURN relay | Relayed media |

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:

| Port | Protocol | Endpoint | Purpose |
| --- | --- | --- | --- |
| UDP 3478 (alt. UDP 443) | TURN | turn.cloudflare.com | Relay over UDP |
| TCP 3478 (alt. TCP 80) | TURN | turn.cloudflare.com | Relay over TCP |
| TCP 5349 (alt. TCP 443) | TURN over TLS | turn.cloudflare.com | Relay over TLS |
| UDP 3478 | STUN | stun.cloudflare.com | NAT discovery |

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

Local · discovery

## 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.

| Port | Protocol | Multicast address | Purpose |
| --- | --- | --- | --- |
| UDP 5353 | mDNS | 224.0.0.251 | AirPlay + Mersive discovery (Bonjour) |
| UDP 1900 | SSDP | 239.255.255.250 | Google Cast / UPnP discovery |

Inter-VLAN · Pod-side ports

## 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.

| Port | Protocol | Purpose |
| --- | --- | --- |
| TCP 7000 | AirPlay | AirPlay service |
| TCP 7001 | AirPlay | AirPlay mirroring |
| TCP 7100 | AirPlay | AirPlay control channel |
| TCP 7236 | Miracast | Miracast RTSP / control |
| TCP 8008 | Google Cast | Cast HTTP |
| TCP 8009 | Google Cast | Cast TLS |
| TCP 8443 | Mersive | Mersive secure service |
| TCP 443 | HTTPS | Reachability (diagnostic validation) |

| Port range | Protocol | Direction | Purpose |
| --- | --- | --- | --- |
| UDP 40000–49999 | RTP/RTCP | Client VLAN ⇄ Pod VLAN | WebRTC media stream (screen sharing), bidirectional |

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.

Reference architecture

## 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.

| Traffic flow | Ports | Purpose |
| --- | --- | --- |
| VLAN 10 (client) → internet | TCP 443 outbound | The 14 cloud endpoints above |
| VLAN 20 (pod) → internet | TCP 443 outbound | The 14 cloud endpoints above |
| VLAN 10 → VLAN 20 | TCP 7000–7001, 7100, 7236, 8008–8009, 8443 | Casting and discovery |
| VLAN 10 ⇄ VLAN 20 | UDP 40000–49999 | WebRTC media (screen sharing) |
| Both VLANs → internet | UDP 19302 outbound | STUN (NAT traversal) |
| Both VLANs → internet | UDP/TCP 3478, UDP 49152–49751 outbound | TURN relay (when enabled for your organization) |
| Both VLANs → internet | UDP 123 outbound | NTP time sync |
| VLAN 20 (local) | UDP 5353, 1900 multicast | mDNS / SSDP discovery |

Pod connection diagram from the hardware library. This image shows physical connections; use the tables above for network traffic requirements.

Validate the deployment

## 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.

| Command | What it does |
| --- | --- |
| python3 mersive\_network\_diag.py | Opens the diagnostic in your browser and runs the full check |
| python3 mersive\_network\_diag.py --quick | Five-second smoke test: DNS, STUN, NAT, and NTP |
| python3 mersive\_network\_diag.py --cloud-only | DNS and TLS checks against the 14 cloud endpoints |
| python3 mersive\_network\_diag.py --pod-ip 10.0.2.50 | Adds a cross-VLAN probe against a specific pod |
| python3 mersive\_network\_diag.py --json | Machine-readable output |
| python3 mersive\_network\_diag.py --send-to-support | Saves the report and opens your email client, addressed to support |

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 →](https://www.mersive.com/platform/cross-network)