Firewall and NAT, made simple.

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. Sub-5 ms latency. 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 Remio relay node over TLS port 443, 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.

KEY TAKEAWAY

You never have to open inbound ports on a router or firewall to run Remio. Both the client and host only make outbound connections. If your network allows you to load https://remio.net in a browser, Remio's connection server is reachable. If it can load YouTube or Zoom, Remio's media path almost certainly works too.

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. 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 a relay node, 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 with AES-256-GCM 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 and relay fallback
ALLOW  TCP/443    ->  relay.remio.net           (TLS, WebSocket + relay)
ALLOW  UDP/443    ->  relay.remio.net           (relay over UDP — optional, preferred)

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

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

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

If you can only allow one rule, allow outbound TLS on port 443 to relay.remio.net — that single rule is 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 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 a Remio relay node. 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. Sub-5 ms 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.

TIP

Tap the connection-path indicator to see additional diagnostics — public IP of each end, current round-trip time, and which relay region (if any) is in use. This is the first thing to check when reporting a connection issue to support.

What the relay can and cannot see

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

• End-to-end encryption. Every frame, every keystroke, every audio sample is encrypted with AES-256-GCM 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.
• No content logging. Relay nodes do not record packet payloads or any other session content. Operational logs include only connection events (connect, disconnect, region), bytes-relayed counts, and error codes.
• 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 TLS port 443 to relay.remio.net, and if there's a TLS inspection proxy, add the same hostname 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, and add a bypass entry.
• "Other video apps work, only Remio fails" — almost always TLS inspection or deep packet inspection mangling the WebRTC handshake. The fix is the same: ask IT to add relay.remio.net 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 disabling split-tunnel routing for relay.remio.net if your VPN supports it.

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 + relay
OUTBOUND UDP/443  ->  relay.remio.net           # relay over UDP (optional)

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

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