Cameras

View cameras remotely without the cloud

Reach your NVR and cameras from anywhere without a camera-vendor cloud — a mesh VPN (Tailscale/WireGuard) to the NVR instead of port-forwarding, and why you never expose a camera directly.

Problem summary

The safe way to watch cameras remotely is to reach the NVR over a private tunnel, not to port-forward a camera or NVR to the internet (cameras are a notorious source of exposed, exploited devices). A mesh VPN like Tailscale or WireGuard to the NVR — or a subnet router onto the camera VLAN — gives you full access with nothing published.

Operator snapshotEvidence first

First proof

Confirm nothing camera-related is port-forwarded to the internet.

Screen to open

From a remote device on the tailnet: ping/open the NVR's MagicDNS name or tailnet IP

Expected signal

No camera or NVR port is exposed on the WAN.

Stop boundary

Never expose the NVR login directly to the internet without a tunnel/auth layer.

Layer path

1The safe pattern is to reach the NVR over a private tunnel, never to port-forward a camera or NVR to the internet — internet-exposed cameras/NVRs are among the most-scanned and most-exploited devices and often ship weak default credentials.

2A mesh VPN (Tailscale or plain WireGuard) on the NVR — or a subnet router onto the camera VLAN — gives full local-quality access with nothing published; both ride the WireGuard protocol.

3Tailscale wraps WireGuard with key management, NAT traversal, and MagicDNS; its free Personal plan currently allows 6 users and 100 devices, enough for a household. Verify the limit before relying on it.

4This works behind CGNAT (no public IPv4) because the tunnel connection is outbound — the very situation where port-forwarding fails.

Runbook

Step-by-step runbook

Start here. Do each check in order, compare it to the expected result, and stop when the evidence explains the failure or the safe stop point applies.

Stop exposing cameras/NVR

Check: Remove any port-forward to a camera or the NVR.

Expected result: Nothing camera-related is reachable from the WAN.

If not: If you must keep a service public, put it behind an authenticated proxy/tunnel.

Choose and install a tunnel

Check: Install Tailscale on the NVR (or run a subnet router onto the camera VLAN), or set up plain WireGuard.

Expected result: There's a private endpoint you can reach from outside.

If not: Pick Tailscale for managed NAT traversal/MagicDNS; WireGuard for a minimal self-hosted tunnel.

Connect your devices

Check: Join your phone/laptop to the tailnet (free plan allows 6 users, 100 devices).

Expected result: Remote devices reach the NVR by name with nothing published.

If not: Add household users to the tailnet rather than sharing one account where possible.

Keep cameras isolated

Check: Ensure only the NVR/endpoint is on the tunnel; cameras stay on their no-internet VLAN.

Expected result: You reach the NVR; the NVR reaches the cameras locally.

If not: Don't bridge the cameras onto the tunnel directly.

Fix remote live-view latency if needed

Check: Use go2rtc MSE/WebRTC for live view and make sure the WebRTC port is reachable over the tunnel.

Expected result: Live view is near-real-time remotely.

If not: If WebRTC won't connect, fall back to MSE — see /cameras/go2rtc-low-latency-live-view.

Decision tree

If: You want the simplest secure remote view.

Then: Mesh VPN to the NVR.

Action: Install Tailscale on the NVR; connect your phone/laptop to the tailnet and open the NVR by its name.

If: You're behind CGNAT / have no public IP.

Then: Port-forwarding is out; mesh VPN still works.

Action: Use Tailscale/WireGuard (outbound NAT traversal); don't chase port-forwarding.

If: You want browser access for several household users.

Then: Tailnet sharing or an authenticated reverse proxy.

Action: Add users to the tailnet (free plan allows 6), or front the NVR with an authenticated reverse proxy over the tunnel.

Safe stop: Never expose the NVR login directly to the internet without a tunnel/auth layer.

If: Live view is laggy once you're connected remotely.

Then: WebRTC candidate/codec issue, not the tunnel.

Action: Use go2rtc MSE/WebRTC and ensure the WebRTC port is reachable over the tunnel — see /cameras/go2rtc-low-latency-live-view.

Evidence

Evidence table

Symptom	Evidence to collect	Likely layer	Next action
Want to watch cameras away from home.	Whether an endpoint can run a VPN; CGNAT status.	Remote-access method	Mesh VPN to the NVR; never port-forward a camera.
Port-forward won't work at all.	WAN IP in the CGNAT range.	CGNAT	Switch to a mesh VPN (outbound).
Multiple users need access.	Tailnet user count vs the free-plan limit.	Sharing / accounts	Add tailnet users (6 free) or an authenticated proxy.
Remote live view lags.	Whether WebRTC's port/candidate is reachable over the tunnel.	Live-view transport	go2rtc MSE/WebRTC with a reachable port over the VPN.

Reference

Commands and settings paths

Confirm the NVR is reachable over the tailnet

From a remote device on the tailnet: ping/open the NVR's MagicDNS name or tailnet IP

Where: On a phone/laptop joined to the tailnet, off the home network.

Expected: The NVR responds by its tailnet name with no port-forward in place.

Failure means: If it doesn't, the endpoint isn't advertising the route or the NVR isn't on the tunnel.

Safe next step: Install the VPN on the NVR or advertise the camera-VLAN subnet via a subnet router.

Check for an accidental WAN exposure

From outside the network: scan/connect to your WAN IP on the NVR/camera ports

Where: From a remote network (not home).

Expected: The NVR/camera ports are NOT reachable from the public internet.

Failure means: Any open camera/NVR port from outside is a live exposure to fix immediately.

Safe next step: Remove the port-forward; rely on the VPN.

Detect CGNAT

Compare the router's WAN IP to a public 'what's my IP' result; check for 100.64.0.0/10

Where: On the home router's WAN status page.

Expected: If they differ or the WAN IP is in 100.64.0.0/10, you're behind CGNAT.

Failure means: CGNAT means no inbound port-forward is possible.

Safe next step: Use a mesh VPN; don't attempt port-forwarding.

Hardware boundary

Hardware and platform boundary

Change only when

Move to a mesh VPN the moment you want remote viewing — it replaces risky port-forwarding and works behind CGNAT.

Evidence that matters

An always-on endpoint to host the tunnel (the NVR or a small always-on box), and a mesh-VPN account within its free limits.

Evidence that does not matter

A public IP or DDNS for the cameras — you don't need to expose anything when the tunnel is outbound.

Avoid

Port-forwarding a camera/NVR, reusing default camera credentials, or bridging cameras directly onto the VPN.

Related tool/calculator

Use the linked calculator or tool to turn this runbook into numbers for your exact setup.

Device setup troubleshooter

Last reviewed

2026-06-03 · Reviewed by HomeTechOps. Built from June-2026 research verified against Tailscale (the free Personal plan now allows 6 users / 100 devices), the WireGuard protocol, and the CGNAT range; leads with never-expose-a-camera, the mesh-VPN-to-the-NVR pattern, and why it works behind CGNAT, cross-linking the isolation, go2rtc, and remote-access pages. Free-tier limits change — re-verify before relying on them.

Sources/assumptions

Assumes a self-hosted NVR (Frigate/Blue Iris/Scrypted/Synology) you want to reach from outside the home.
Cameras stay on their isolated VLAN with no internet; only the NVR (or a tunnel endpoint) is reachable remotely.
Mesh-VPN free-tier limits change — verify the current Tailscale plan limits before relying on them.

Source-backed checks

HomeTechOps turns official docs and conservative safety rules into a shorter runbook. These links are the source trail for the page direction.

Frigate docs: Recommended hardwareUsed for detector inference times, the cameras ≈ (1000 ÷ inference_ms) ÷ detect_fps capacity model, and the current 'Coral no longer recommended for new installs' guidance.Frigate docs: Camera setup (detect vs record streams)Used for the detect-on-substream / record-on-main pattern that drives bandwidth and detector load.FS.com: Understanding PoE standards and wattageUsed for the 802.3af/at/bt source-vs-delivered power figures and the switch total-PoE-budget constraint.Tailscale: Subnet routersUsed for VPN routing, subnet overlap, and local-network reachability assumptions.Tailscale: Pricing v4 (April 8, 2026)Used for the April 2026 Tailscale pricing change: free Personal plan = 6 users + unlimited user devices, 50 tagged resources, exit nodes free on all tiers.WireGuard — official siteUsed for WireGuard as the modern kernel/userspace VPN underlying mesh tools (e.g. Tailscale) for reaching an NVR remotely without exposing it.RFC 6598: IANA-reserved IPv4 prefix for shared address spaceUsed for the authoritative CGNAT detection rule: WAN IP in 100.64.0.0/10 means no port-forward is possible without a tunnel.

Diagnostic rule

1. Check the simplest signal first.
2. Change one thing at a time.
3. Prove the stream/reachability before deep config.
4. Stop when the evidence says the risk moved.

FAQ

Can I just port-forward my camera or NVR to watch it remotely?

Don't. Internet-exposed cameras and NVRs are one of the most-scanned, most-exploited classes of device, and many ship weak default credentials. Instead, run a mesh VPN (Tailscale/WireGuard) on the NVR or a small box on its network and connect to that — you get full local-quality access with nothing published to the internet. See the safe remote-access ladder.

Tailscale or WireGuard for reaching the NVR?

Both ride the WireGuard protocol. Plain WireGuard is a lightweight, self-managed tunnel; Tailscale wraps WireGuard with key management, NAT traversal, and MagicDNS, and its free Personal plan currently allows 6 users and 100 devices — enough for a household. Install it on the NVR (or run a subnet router onto the camera VLAN) and the NVR is reachable by its tailnet name. Compare options in Tailscale vs Cloudflare Tunnel.

My ISP uses CGNAT — does that block remote camera access?

It blocks port-forwarding (you have no public IPv4), but not a mesh VPN — Tailscale/WireGuard with NAT traversal work fine behind CGNAT because the connection is outbound. That's another reason to prefer a tunnel over port-forwarding. See CGNAT and no public IP.