How to reach CCTV remotely without a static IP or port forwarding
Every common way to reach a recorder or camera from outside the site, with what each needs and what each leaves out.
You do not need a static IP or port forwarding to reach CCTV remotely: anything at the site that connects outward can carry the connection instead. A static IP is needed only for port forwarding and for a VPN hosted on the site's own router.
This guide compares the usual methods: what each needs at the site, what it costs in effort, and where it stops working.
The short answer
There are two kinds of method.
- Inbound methods wait for a connection from outside: port forwarding, dynamic DNS and a VPN server on the router. They need the site to have a public address. Behind CGNAT (carrier-grade NAT: the site shares a public address with many others, so nothing can be forwarded to it) they do not work.
- Outbound methods start the connection from inside the site: the camera maker's P2P app, a mesh VPN, a tunnel service and a box that dials out. They need no public address, so CGNAT does not matter to them.
4G, 5G and Starlink sites are almost always behind CGNAT, so only outbound methods work there. The CGNAT guide shows how to tell whether a fixed-line site is.
Port forwarding with a static IP
A rule on the site's router sends one outside port to one camera or recorder inside. A static IP gives the site an address that does not change.
- Needs: a public address on the router, router access, and a rule for each device.
- Costs: nothing beyond the router, plus the provider's fee for a static IP. 2degrees, for example, charges NZ$10 a month on home plans (2degrees, read 16 October 2026).
- Stops working: behind CGNAT, where traffic from outside never reaches the router.
- Security: each forwarded port answers anyone who finds it. What they reach is the device's own login page.
Relayant and port forwarding compares it with our box in more detail.
Dynamic DNS
Dynamic DNS gives the site a name that follows the router's public address when the provider changes it. It replaces the static IP, not the port forward: the rules on the router are still needed.
- Needs: a public address (even a changing one), a dynamic DNS client on the router or recorder, and the port forwards.
- Costs: free and paid tiers.
- Stops working: behind CGNAT. The router has no public address of its own, so the name has nothing to point at.
- Security: the same as port forwarding.
The camera maker's P2P app
Camera and recorder makers have their own apps and clouds for their own devices. Hik-Connect is Hikvision's, for Hikvision devices; DMSS is Dahua's app for individual users. The recorder is registered with the maker's cloud, and you reach it through the maker's app or portal (Hikvision and Dahua, read 13 October 2026).
- Needs: the maker's devices, and an account with the maker.
- Costs: set by the maker.
- Stops working: for another maker's devices, and for a control room's monitoring software, which connects by address and port rather than through an app.
- Security: the connection goes through the maker's service.
Camera makers' P2P clouds compares them with our box.
A VPN on the site's router
Many routers can run a VPN server. A control room PC connects to it and is then on the site's network.
- Needs: a router that runs a VPN server, a public address for the router, and the VPN client on each PC that connects.
- Costs: usually nothing beyond the router.
- Stops working: behind CGNAT, for the same reason as port forwarding: the connection to the router starts outside.
- Security: only VPN users get in, but once in they are usually on the whole site network.
A mesh VPN with a subnet router
Mesh VPNs such as Tailscale and ZeroTier connect outward, so CGNAT does not stop them. Their client cannot be installed on a camera or a recorder. Tailscale's own documentation says IP cameras, printers and similar devices cannot run it directly (Tailscale, read 16 October 2026).
Instead, a computer at the site runs the VPN and passes traffic to the devices on its network: a subnet router for Tailscale, a bridge for ZeroTier. That computer has to stay on.
- Needs: a computer at the site that stays on and is looked after, and the VPN client on each PC that connects.
- Costs: the free tiers are for non-commercial use; paid tiers are per user (Tailscale) or per device (ZeroTier), read 13 October 2026.
- Stops working: when the computer at the site is off, asleep or out of date.
- Security: only the VPN's members get in. With a Tailscale subnet router, they reach every address on the site's subnet once the route is approved.
Relayant and Tailscale or ZeroTier compares them with our box.
Other tunnel services
Cloudflare Tunnel. The cloudflared program runs on a computer in the site's network, signed in to your Cloudflare account, and connects outward. It is built for web servers first. Reaching a device by address and port needs the Cloudflare One Client on each control room computer (Cloudflare, read 13 October 2026). See Relayant and Cloudflare Tunnel.
Teltonika RMS. If the site's router is a Teltonika, its RMS service reaches devices behind it over RDP, VNC, SSH or HTTP(S) without a public address (Teltonika, read 13 October 2026). See Relayant and Teltonika RMS.
A box that dials out
This is what we do. A Relayant box plugs into a spare LAN port on the site's router and takes an address by DHCP. It connects out to Relayant over an encrypted WireGuard tunnel. Nothing is opened or forwarded on the router.
- Needs: a spare LAN port, power, and outbound internet. Fibre, DSL, 4G, 5G and Starlink all work.
- Costs: priced per box per month; see Pricing.
- Stops working: on a network that blocks outbound UDP, which some private APNs and business firewalls do.
- Security: the relay reaches only the device-and-port pairs you chose, never the whole site network. Only the internet addresses you list can connect.
Each device you choose gets one address and port on Relayant, which your monitoring software connects to directly. The box also checks every monitored device every minute and reports when one stops answering. How Relayant works has the whole mechanism.
The methods side by side
| Method | Public address needed | Works behind CGNAT | At the site | Who can reach the device |
|---|---|---|---|---|
| Port forwarding and a static IP | Yes | No | A rule per device on the router | Anyone who finds the port |
| Dynamic DNS | Yes, but it may change | No | A rule per device, plus the dynamic DNS client | Anyone who finds the port |
| The maker's P2P app | No | Not covered here | The maker's devices, registered with its cloud | People signed in to the maker's app |
| A VPN on the router | Yes | No | A router that runs a VPN server | VPN users, usually on the whole network |
| A mesh VPN | No | Yes | A computer that stays on, as a subnet router or bridge | VPN members, on the whole subnet with a Tailscale subnet router |
| Cloudflare Tunnel | No | Yes | A computer running cloudflared | Computers enrolled with the Cloudflare One Client |
| A Relayant box | No | Yes | The box, on a LAN port | Only the addresses you list, only the ports you chose |
"Not covered here" means the makers' pages we read do not say either way.
Choosing one
A fixed line with a public address and one or two devices. Port forwarding, with a strict rule on who may connect, is the least to set up. Dynamic DNS covers an address that changes.
One maker's devices, viewed on phones. The maker's app does the job and needs nothing added to the site.
A computer already runs at the site, and you look after it. A mesh VPN on that computer reaches the devices behind it.
Sites behind CGNAT, many sites, or a control room whose monitoring software connects by address and port. A box that dials out removes the router work and the public address, and tells you when a device stops answering.
Something in this guide is wrong or missing? Tell us: hello@relayant.net.