Firewall and NAT, made simple.

Most users never touch a firewall setting to use Remio. The app is built on the same connection technology that lets video-calling apps work behind home routers, hotel Wi-Fi, and corporate VPNs — it figures out the path on its own. But for the small number of users on locked-down networks where the default just hangs, this page is the one-stop reference: what Remio actually sends over the wire, what to allow on the firewall, how to read the in-session diagnostics, and what to say to IT.

Overview

Remio uses a layered approach to connect a client to a host. It tries the fastest path first, then falls back gracefully as needed. There are three possible paths, in this order of preference:

1. Direct on the same network — client and host on the same Wi-Fi or LAN. Frames travel point-to-point. About 8 ms of processing latency — your input lands before the next frame draws. This is what you get at home, in a single-office network, or over Tailscale/WireGuard.
2. Direct across the internet (peer-to-peer) — client and host on different networks but each able to make an outbound UDP connection. Both ends exchange their public addresses via Remio's connection server, then send media directly to each other. 10 to 40 ms additional latency depending on geography.
3. Relay fallback — when UDP is blocked or NAT is too restrictive for a direct path, both ends connect outbound to a relay server (Cloudflare's global network, turn.cloudflare.com) — over UDP when it can, over TCP or TLS on port 443 when UDP is blocked — and the relay forwards encrypted media between them. 30 to 80 ms additional latency. Works wherever HTTPS works.

You don't pick the path manually. Remio probes all three simultaneously at the start of every session and uses the fastest one that succeeds. If the network changes mid-session (you walk from office Wi-Fi to LTE), Remio re-probes and switches paths without dropping the session.

How a Remio session traverses a firewall

From the moment you tap Connect in the client, here's the sequence:

1. Outbound TLS to the connection server. Both client and host open a long-lived WebSocket to relay.remio.net on port 443. This carries pairing handshakes, the offer/answer exchange, and a small amount of control traffic for the lifetime of the session. No screen or input data ever goes through it. It's standard HTTPS — every corporate firewall lets it through.
2. Network probing. Each end uses the public STUN service to discover its own public address (the address the rest of the internet sees). It then asks the connection server for short-lived credentials to the relay (turn.cloudflare.com), in case probing fails.
3. Path race. Both ends simultaneously try direct UDP, direct UDP via STUN-discovered addresses, and TLS relay. Whichever combination succeeds and pings back first wins. Most home networks pick direct UDP within 200 ms; restricted networks fall through to TLS relay within about 2 seconds.
4. Encrypted media flow. Once the path is chosen, every video frame, every keystroke, every audio sample is encrypted end to end and sent over the chosen path. Even on the relay path, the relay node sees only ciphertext.

This entire process is invisible to you — the client just shows "Connected." But understanding the sequence makes the firewall rules in the next section make sense.

What to allow on the firewall

For IT teams writing a firewall policy, here's the complete list of outbound traffic Remio generates. No inbound rules are ever needed.

# Outbound rules — Remio Client and Remio Host

# Required — connection setup (signaling only, no media)
ALLOW  TCP/443    ->  relay.remio.net           (TLS WebSocket)

# Required — relay fallback (media when no direct path exists)
ALLOW  TCP/443    ->  turn.cloudflare.com       (TURN over TLS — works when UDP is blocked)
ALLOW  UDP/3478   ->  turn.cloudflare.com       (TURN over UDP — optional, preferred)
ALLOW  UDP/443    ->  turn.cloudflare.com       (TURN over UDP — optional)

# Strongly recommended — enables direct peer-to-peer (lower latency)
ALLOW  UDP        ->  any (high ports 32768-65535)

# Optional — used during initial address discovery only
ALLOW  UDP/3478   ->  stun.cloudflare.com
ALLOW  UDP/19302  ->  stun.l.google.com

# Not required, never used
DENY   any inbound                              (nothing inbound is ever needed)

If you can only allow the minimum, allow outbound TCP port 443 to relay.remio.net and to turn.cloudflare.com — those two rules are enough for Remio to function end-to-end, just over the relay path instead of direct. Sessions still encrypt and stream at full quality; latency is the only cost.

Common corporate-network scenarios

Real-world firewall configurations span a wide range. Here's what to expect in each.

Default-allow outbound (most small offices, home networks)

The firewall lets out any outbound TCP and UDP, blocking only specific bad-actor ranges. Remio finds a direct UDP path within a second and stays there. Latency is whatever your internet round-trip is, plus 3 to 5 ms of Remio overhead. You see Direct in the connection-type indicator.

UDP-blocked outbound (mid-sized enterprises, schools)

The firewall allows TLS and a handful of well-known protocols, but blocks outbound UDP wholesale to prevent peer-to-peer abuse. Remio's direct UDP probe fails, the TLS-443 relay probe succeeds, and the session establishes over the relay path within about 2 seconds. The connection-type indicator shows Relay. Latency adds 30 to 80 ms depending on your distance to the nearest relay node. Streaming, audio, keyboard, and input all work the same.

TLS-inspecting proxy (large enterprises, finance, healthcare)

The firewall decrypts every outbound TLS connection, inspects the contents, and re-encrypts before forwarding. This is the trickiest case. Two things can go wrong:

• The proxy doesn't recognize the long-lived media-style flow Remio uses, and either drops it after a short timeout or rate-limits it to the point of unusability.
• The proxy strips parts of the connection handshake it doesn't understand, leaving Remio stuck.

The fix is to add relay.remio.net and turn.cloudflare.com to the proxy's TLS-inspection bypass list. Every major enterprise proxy (Zscaler, Palo Alto, Cisco Umbrella, Check Point, Forcepoint) supports per-domain bypass. The traffic still flows through the corporate firewall — it just isn't decrypted on the way through. IT teams typically add bypass entries for video conferencing apps (Zoom, Teams) for the same reason; Remio fits the same pattern.

Captive portal / hotel Wi-Fi

Many hotels and airports use a captive portal that blocks all outbound traffic until you accept terms. Once you've authenticated, most allow normal HTTPS, which means Remio's relay path works. UDP is hit-or-miss — some portals continue to block UDP even after sign-in. If a session feels sluggish on hotel Wi-Fi, check the indicator — it almost always shows Relay. There's nothing to fix; that's the expected mode for these networks.

Carrier-grade NAT on mobile networks

4G/5G connections often sit behind multiple layers of NAT operated by the carrier, which makes direct peer-to-peer difficult. Remio handles this transparently — direct UDP usually works for one direction (the mobile client reaching the host), and the relay path is always available as a fallback. Performance over LTE/5G is typically excellent.

Verifying the connection path

Every Remio client exposes the chosen connection path in the in-session stats overlay. Open it from the toolbar — the icon is a small bar-chart glyph. You'll see:

• Connection — Direct means peer-to-peer over UDP. Lowest latency. Frames travel straight from host to client without intermediate hops.
• Connection — Relay means traffic is routed through the relay (turn.cloudflare.com). Adds 30 to 80 ms latency. Still end-to-end encrypted — the relay sees only ciphertext.
• Connection — LAN appears when both endpoints are on the same local network. About 8 ms of processing latency, no internet round-trip.

If you expect Direct but see Relay, the network you're on is blocking UDP somewhere along the path. The session still works, just with extra latency. On a network you control (your home router), check QoS settings and any "gaming mode" toggles that sometimes break UDP forwarding.

What the relay can and cannot see

A common concern on the relay path is privacy: if my screen is going through a relay server, can anyone there see it? No. Here's why:

• End-to-end encryption. Every frame, every keystroke, every audio sample is encrypted using a session key derived during the handshake. Only the client and host hold the key. The relay forwards ciphertext.
• No key escrow. Remio's servers never see or store session keys. Even with full access to relay logs and physical control of the relay servers, Remio cannot decrypt any user session — past, present, or future.
• Nothing readable to log. The relay only ever handles encrypted packets, and Remio's own connection server (relay.remio.net) carries setup messages only — never screen, audio, or input.
• Corporate TLS inspection bypass works too. Because the media is encrypted at a layer above TLS (the encryption happens before TLS wraps the packet for the relay), a corporate TLS proxy decrypting the outer TLS still sees only the inner encrypted payload. There is no way for any middlebox to read your screen.

For the full encryption story see Security & encryption.

Troubleshooting connection issues

• "Connection fails on corporate Wi-Fi but works at home" — UDP is blocked outbound and the TLS relay path is also being blocked or stripped. Ask IT to allow outbound TCP port 443 to relay.remio.net and turn.cloudflare.com, and if there's a TLS inspection proxy, add the same two hostnames to its bypass list. This unblocks the relay path; sessions then work end-to-end.
• "Latency is much higher than expected on the office network" — the connection is probably going through the relay (check the in-session indicator). Relay paths add 30 to 80 ms. If IT can open outbound UDP, Remio will switch to the direct path automatically and latency will drop.
• "Connection establishes but stream freezes after a few seconds" — typical of a TLS inspection proxy that allows the initial handshake but kills long-lived flows. Confirm in IT logs whether the proxy is interrupting relay.remio.net or turn.cloudflare.com, and add bypass entries for both.
• "Other video apps work, only Remio fails" — almost always TLS inspection or deep packet inspection mangling the handshake. The fix is the same: ask IT to add relay.remio.net and turn.cloudflare.com to the inspection bypass list.
• "Sometimes it works, sometimes it hangs at 'Connecting'" — flaky DNS resolution for relay.remio.net, or a corporate DNS filter blocking the connection server. Try nslookup relay.remio.net from the same machine — it should return an IP within a second. If it times out or fails, DNS is the bottleneck.
• "Connect button does nothing — no errors, no progress" — outbound port 443 is being blocked entirely. This is unusual but happens on heavily restricted networks. Test by loading https://relay.remio.net/health in a browser; it should return a short status response. If the browser also can't reach it, the firewall is fully blocking outbound HTTPS to that host.
• "VPN client breaks Remio when it connects" — some VPN agents capture all traffic including media, which causes a stutter. Try excluding relay.remio.net and turn.cloudflare.com from the tunnel if your VPN supports split tunnelling.

Advanced — locking it down further

If your security team needs the tightest possible allowlist, the following is the minimum that still lets Remio operate end-to-end:

# Minimum-viable firewall allowlist
# Allows relay-mode operation only (~30-80 ms latency)

OUTBOUND TCP/443   ->  relay.remio.net          # connection setup
OUTBOUND TCP/443   ->  turn.cloudflare.com      # relay (TURN over TLS)

# Adding these unlocks direct peer-to-peer (3-5 ms LAN, 10-40 ms WAN)
OUTBOUND UDP/3478  ->  stun.cloudflare.com      # public address discovery
OUTBOUND UDP/19302 ->  stun.l.google.com        # public address discovery (redundancy)
OUTBOUND UDP       ->  any (32768-65535)        # direct media path

The first two lines alone are enough for the app to work — every other line is a latency optimization. If you want both maximum security and lowest latency, allow all five.

Firewall and NAT questions

Does Remio require opening inbound ports on my firewall?

No. Both the Remio Client and Remio Host only make outbound connections. There is nothing to open on your router or your firewall's inbound rules. If your network allows normal outbound web traffic — loading websites, using a messaging app — Remio works.

What ports does Remio use?

Outbound TCP 443 to relay.remio.net for connection setup, and outbound traffic to the relay (turn.cloudflare.com) when no direct path exists: UDP 3478 or 443 when it can, TCP or TLS on port 443 when UDP is blocked. Direct peer-to-peer media uses outbound UDP on random high ports; public-address discovery uses UDP 3478 (stun.cloudflare.com) and UDP 19302 (stun.l.google.com). No inbound ports are required on either side.

Does Remio work on corporate networks that block UDP?

Yes. When UDP is blocked, Remio automatically falls back to relaying media over TLS on port 443 — the same port your browser uses for HTTPS. Connections take a fraction of a second longer to establish and add about 30 to 80 ms of latency, but the session works end to end. There is no setting to flip — the fallback happens transparently.

Can my IT team inspect Remio traffic?

No. All session media is end-to-end encrypted — your screen never touches our servers, and even the relay only ever sees ciphertext. Even when traffic goes through the relay on port 443, the relay only forwards encrypted packets — it cannot read screen contents, keystrokes, or any other data. Corporate TLS-inspection proxies cannot see inside the stream either because the media is encrypted at a layer above TLS.

Why does my connection work at home but fail at the office?

Corporate networks frequently block UDP entirely and may also block outbound TLS to non-allowlisted hosts. Ask IT to allow outbound TCP port 443 to relay.remio.net (connection setup) and to turn.cloudflare.com (the relay that carries media when UDP is closed). Those two entries are enough for Remio to work with UDP fully blocked.

How do I check whether my session is direct or relayed?

Open the in-session stats overlay from the toolbar. Every Remio client shows a connection-type indicator — Direct, LAN, or Relay — alongside latency and bitrate. Direct connections feel snappier; relayed connections add roughly 30 to 80 ms latency depending on your distance to the nearest relay node.

Does Remio work behind a VPN or zero-trust agent?

Yes, in almost every case. Both peer-to-peer and relay paths use standard outbound HTTPS, which corporate VPNs and zero-trust agents (Zscaler, Cloudflare WARP, Tailscale, Twingate) pass cleanly. Some aggressive deep-packet-inspection middleboxes can mangle the stream — see the troubleshooting section above for workarounds.

Will my company's TLS interception break Remio?

It can. Deep-packet inspection proxies that decrypt and re-encrypt all TLS connections sometimes strip parts of the connection handshake or block the long-lived nature of media flows. If you see Remio fail only on your corporate network, ask IT to add relay.remio.net and turn.cloudflare.com to the TLS inspection bypass list — most enterprise proxies (Zscaler, Palo Alto, Cisco Umbrella, Check Point) support per-domain bypass.

Related guides

• Set up Mac to Mac — base setup before tuning the network path.
• Set up Mac to iPad — same network logic, iPad client.
• Stream Windows PC to Mac — same network logic, Windows host.
• Direct LAN connection Admin windows & UAC — when you want guaranteed peer-to-peer on your own network.
• Troubleshooting — broader catch-all for connection issues.
• Security & encryption — full detail on end-to-end encryption.