Should I port forward my security camera?

No. Cameras commonly ship with default credentials, receive firmware updates rarely or never, and are indexed by search engines built to find exposed devices. Every device on a public address is scanned continuously: across 141,348 requests to our own site we logged 6,985 hostile probes across 707 distinct paths, and that is a site with nothing valuable on it. Choosing an unusual port does not help, because scanners sweep the whole range.

How do I view my IP camera from outside my network safely?

Install a mesh VPN such as Tailscale on an always-on machine on the camera network and advertise that subnet, then accept routes on your phone. Your phone joins a private network that includes the camera LAN, so the camera's normal app and web interface work from anywhere while nothing is exposed to the internet. Enable IP forwarding on the subnet router first and approve the advertised route in the admin console, or it will report healthy while carrying no traffic.

Can I access my NVR remotely if I am behind CGNAT?

Yes, but not by port forwarding or by running a VPN server on your router, since both need an inbound public address that carrier-grade NAT does not give you. A mesh VPN and the vendor's own cloud app both still work because they dial outward. If external software genuinely requires a directly reachable address, a routable public IP attached to a machine you maintain is the remaining option.

Is the camera manufacturer's cloud app safe to use?

It is a reasonable trade if you understand it. Nothing is exposed to the internet and it works behind CGNAT, but your video is brokered by the vendor's infrastructure, the feature lasts only as long as they run the service, and your account on their portal becomes the attack surface instead of the camera. A reused password there exposes the camera as completely as an open port would, so use a unique password and two-factor.

If I do need a public IP for my cameras, how should I set it up?

Never put the camera itself on the public address. Put a machine you can actually maintain there, such as a small server or an NVR running a real operating system, and let that be the only reachable thing while the cameras stay on the private side. Also disable UPnP on the router so devices cannot open their own inbound ports, put cameras on their own VLAN with no route to the rest of the LAN, and change every default credential before the device touches a network.

Guide

Access an IP Camera or NVR Without Port Forwarding

Do not forward a camera to the internet. It is the first answer most guides give and it is the one that gets people watched: cameras ship with default credentials, receive firmware updates rarely or never, and are indexed by search engines built specifically to find exposed devices. There are three safer ways to reach yours from outside, and for most people the best one is free. If you genuinely need a direct connection — because an NVR app demands one — that is the last option here, with the hardening that makes it defensible.

Why a camera is the worst thing to expose

Every device on a public address gets scanned. That is not a warning, it is an observation: across 141,348 requests to our own site we logged 6,985 hostile probes spanning 707 distinct paths — roughly one request in twenty — and that is a site with nothing interesting on it. A camera attracts the same traffic with three differences that matter:

The credentials are often still the factory ones. Lists of default logins per manufacturer are published, maintained, and the first thing tried.
The firmware is old. Cameras are bought once and forgotten. Many never receive an update, and plenty of vendors stop shipping them within a year or two.
The failure mode is different. A compromised web server is an inconvenience. A compromised camera is somebody watching the inside of your house, and you will not be notified.

Choosing an unusual port does not help. Scanners sweep the whole port range; they are not guessing 80 and giving up.

Option 1: a mesh VPN. Free, and what most people should do

If the people who need to see the cameras are you and your household — which is almost everyone — this is the right answer and it costs nothing.

Install Tailscale on any always-on machine on the same network as the cameras: a Raspberry Pi, a NAS, the NVR itself if it runs something you can install on. Then install it on your phone. Your phone joins a private network that includes the camera's LAN, and the camera's own web interface or app works exactly as it does at home.

# On the always-on Linux box that sits on the camera network.
# IP forwarding FIRST -- without it the subnet router comes up and
# silently carries no traffic.
echo 'net.ipv4.ip_forward = 1' | sudo tee /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale set --advertise-routes=192.168.1.0/24   # your camera LAN

# On the phone or laptop:
sudo tailscale set --accept-routes

One step is easy to miss and is the usual reason this appears not to work: advertised routes must be approved in the Tailscale admin console before anything flows. The subnet router will report itself as up and healthy while carrying nothing at all until you approve the route there.

Nothing is exposed to the internet. The camera does not get an address, does not get scanned, and does not need a firmware update to be safe. We do not sell this and it is still what I would tell a friend to do.

Option 2: the vendor's own cloud

Most cameras ship with a phone app that works from anywhere without configuration. The camera dials out to the manufacturer's servers and your app connects through them, so nothing is exposed and CGNAT is irrelevant.

This is genuinely convenient and worth being clear-eyed about rather than sneering at. The trade is real, though, and it is not the one people assume:

Your video passes through, or is brokered by, the vendor's infrastructure.
Your account becomes the attack surface instead of the camera. A reused password on the vendor's portal exposes the camera as completely as an open port would.
The feature lives as long as the vendor chooses to run the service.

If you use it, put a unique password and two-factor on that account and treat it as seriously as your email.

Option 3: a VPN on the router

If your router supports WireGuard or OpenVPN as a server, you can dial into your home network and reach the cameras as though you were on the sofa. Same security posture as option 1, no third-party service at all.

Two catches. It usually needs an inbound port, which means it needs a public address — so if you are behind CGNAT this option is unavailable for the same reason port forwarding is. And a router VPN is only as maintained as your router's firmware.

Option 4: a public address, when an app insists

Some NVR software and some professional monitoring setups genuinely require a reachable address: RTSP pulled by an external recorder, an integrator's system that will not traverse a mesh, a camera feed consumed by something outside your control.

That is the case a routable address solves, and it is what we sell, so weigh this section accordingly. A small daemon on a machine on the camera network holds a link to our network and we route a public IPv4 address to it. Any port works, and the address is not your home's.

Do not put the camera itself on that address. Put a machine you can actually maintain there — a Pi, a small server, the NVR if it runs a real operating system — and let it be the only thing reachable. The cameras stay on the private side where they belong.

If you are behind CGNAT, options 3 and 4 are the only ones that change

Carrier-grade NAT means your router does not hold a public address, so port forwarding and a router VPN are both off the table regardless of what the camera supports. Options 1 and 2 are unaffected, because both work by dialling outward. Run this on any Linux box on the network to check:

curl -s https://api.ipify.org; echo

Compare it with the WAN address in your router's admin page. If they differ, and the router's is between 100.64.0.0 and 100.127.255.255, that is the shared range reserved for carrier-grade NAT. The Raspberry Pi guide covers the check in more detail.

If anything of yours is reachable, harden it

Change every default credential, on the camera and the NVR, before it touches a network.
Disable UPnP on your router. It lets a device open its own inbound port without asking you, which is how cameras end up exposed by people who never configured anything.
Put cameras on their own VLAN or guest network with no route to the rest of your LAN, so a compromised camera cannot reach anything else.
Block outbound too, if you can. A camera that only needs to talk to your NVR does not need the internet at all.
Update firmware, and if the vendor has stopped shipping updates, treat the device as untrusted and keep it off any reachable network.

Choosing, honestly

Just you and your household? Tailscale. Free, safest, and we do not sell it.
You want the phone app to work with no setup? The vendor cloud, with a unique password and two-factor.
Router supports a VPN server and you have a public address? Use it.
Something external genuinely needs a direct connection? That is the case a routable address solves — on a machine you maintain, never on the camera.

Get a public IP — $10/mo See all plans