View cameras away from home through a user-managed VPN

Preserve a working local connection

Start at home with one camera and one documented video feed. Record the camera address, port, path and codec. Keep the credentials in a password manager and save a redacted version of the connection details for troubleshooting.

Make sure you can repeat the local connection before adding a remote route. Our iPhone setup checklist and RTSP guide explain what to collect. If the local attempt fails, solve that problem first; a VPN route adds another part to check.

This app is still in development. Its architecture targets direct access to reachable cameras through local networks or user-managed routes. We do not operate a camera relay, recording backend or camera-account service. The owner-supplied brief reports simulator tests with fixture video; this website displays a labeled design preview. Remote physical-camera viewing remains untested.

Choose a route into your camera network

Ask the network owner which VPN method is available. A VPN is a private network connection managed outside the camera viewer. Its setup depends on the router, gateway device and VPN software you choose.

Some cameras cannot run a VPN client themselves. A subnet router can provide a route to devices behind it. Tailscale documents this approach and distinguishes subnet access from an exit node that routes internet traffic. Tailscale's subnet router guide covers route advertisement, approval and access rules.

Use that provider's instructions for the actual gateway setup. Decide which camera addresses and services the remote device needs to reach. Keep the access rules focused on your viewing task. This site does not certify a VPN provider or prove the app works with a particular VPN configuration.

Test the route before the video

Use a different network for the remote test, such as mobile data on an iPhone. Check that the VPN client reports a connection. Then verify access to the camera's documented service using a method recommended by the network or camera vendor.

A connected VPN indicator alone cannot tell you whether the camera network route exists or permits the service. Ask the network owner to check the camera subnet, route approval and access rules. Keep those results separate from the camera's stream settings.

Try the same documented feed that worked locally. If your route requires a different reachable address, record that change explicitly while preserving the original local address. Do not change the camera account or codec merely because the network changed.

Keep a repeatable failure record

Compare local and remote attempts in a short table. Include the network used, VPN state, reachable address, stream path and result. Redact account details before sending the table to support. A local success beside a remote timeout points the investigation toward the route without proving which network setting failed.

If the camera responds remotely but video fails, capture the exact error and follow the connection troubleshooting steps. A working route cannot add a missing codec or viewer capability. If you use an HTTP image endpoint, keep the MJPEG or JPEG checks separate from the RTSP result.

Avoid treating VPN use as proof of every privacy claim. The camera, VPN service, network configuration and viewer each have their own behavior. Read their documentation and policies before making assumptions about where traffic travels. For cameras with a documented ONVIF service, collect the details in the ONVIF setup guide before investigating remote access to that service.