Why port forwarding a camera doesn't work on Starlink

Port forwarding a camera doesn’t work on Starlink because Starlink uses CGNAT (carrier-grade NAT) for IPv4 by default, and CGNAT blocks all inbound ports. Your router never gets a public address of its own to forward from. On top of that, the Starlink router can’t port forward at all. The fix is to stop relying on inbound connections. Use a camera app that connects out to the maker’s cloud, or put a mesh VPN like Tailscale on a device at the farm.

This post explains what’s actually happening, how to confirm it on your connection, and the fixes in order of effort.

What CGNAT does to a camera

At a typical home with cable or fiber, the router gets one public IPv4 address. Port forwarding tells the router: “when someone on the internet knocks on port 8000, send them to the NVR.” The camera maker’s guide assumes that setup.

On Starlink, the router doesn’t get a public IPv4 address. It gets a private address in the 100.64.0.0/10 range. Starlink’s own network shares public addresses among many customers, so it has no way to know which customer an unsolicited inbound connection is for, and it drops it. Starlink’s help page says CGNAT blocks all inbound ports.

So there are two separate walls:

1. The Starlink router has no port-forwarding feature. Starlink’s help says you’d need a third-party router and a public IP.
2. Even with your own router, the public side of the connection is shared CGNAT. The forward opens a door on your router, but there’s no door in Starlink’s NAT in front of it.

How to confirm you’re behind CGNAT

You don’t have to take anyone’s word for it.

1. In your router’s status page (or the Starlink app’s network details), find the WAN or internet IPv4 address.
2. On a phone connected to the farm Wi-Fi, search “what is my IP” and note the public IPv4 shown.
3. If the WAN address starts with 100.64 through 100.127, or doesn’t match the public address, you’re behind CGNAT.

That’s true on many cellular home internet services too, not just satellite. It’s why “it worked at our old place on cable” doesn’t carry over.

Which cameras work anyway

The good news: most consumer cameras don’t need port forwarding. They connect out to the maker’s servers, and your phone app connects out to the same place. Outbound connections pass through CGNAT fine.

The full compatibility rundown is in which security cameras work with Starlink.

The fixes, easiest first

1. Turn on the maker’s cloud or P2P connection

Undo the port forward, then in the camera or NVR settings turn on the maker’s remote access feature: UID/P2P on Reolink, Hik-Connect on Hikvision, Lorex Cloud on Lorex, and so on. Add the device in the phone app by scanning its QR code or entering its ID. Test from your phone on cellular data, not the farm Wi-Fi.

Trade-off: your video passes through or is brokered by the maker’s service, and you’re relying on that service staying up. For most farms it’s the right call.

2. A mesh VPN such as Tailscale

If the cameras or NVR are local-only, or you’d rather not use the maker’s cloud, a mesh VPN connects your phone to the farm network directly. Tailscale devices use NAT traversal to set up a direct encrypted tunnel, and fall back to Tailscale’s relay servers when a direct path isn’t possible. No ports are opened. Tailscale’s own write-up on NAT traversal covers CGNAT specifically and says asking users to open ports “is not very user friendly”.

What you need: an always-on device at the farm that can run Tailscale. That can be some NVRs, a small computer, or a router that supports it, set up as a “subnet router” so you can reach the camera’s local address. Then install Tailscale on your phone. The remote viewing guide has the steps. This is for viewing cameras. Using a VPN for remote work is a different topic.

3. IPv6

Starlink gives your network IPv6 addresses, and IPv6 works on all Starlink routers. In theory, IPv6 skips CGNAT because every device gets a globally routable address. In practice, every link has to support it: the camera or NVR, its app, your router’s firewall settings, and the network your phone is on when you’re away. Some mobile carriers and public Wi-Fi networks still hand out IPv4 only. Treat IPv6 as worth a try if you’re comfortable with firewall rules, not as the main plan.

4. A public IPv4 address

Starlink says a public IPv4 comes only with its Local and Global Priority plans. Even then the Starlink router can’t port forward, so you’d need your own router in bypass mode. Plan costs aren’t covered here. Ask whether options 1 or 2 already solve your problem first, because they usually do. See bypass mode and cameras.

Dead ends to skip

• DDNS. A dynamic DNS name points to an address. Behind CGNAT that address is shared, with no route back to you. Lorex says its DDNS option needs forwarded ports, which can’t work behind CGNAT.
• UPnP. It asks your router to open a port. Same problem: Starlink’s NAT is still in front.
• Changing ports. Forwarding 8000, 80, 443 or 554 makes no difference. Hikvision lists HTTP 80, server 8000 and RTSP 554 as the ports to forward for direct access. None of them reach you behind CGNAT.
• Double-checking the forward over and over. If the WAN address is in the 100.64 range, the forward isn’t the problem.

Worked example: an NVR in the barn, viewing from town

The setup: an 8-channel NVR in the barn office, four PoE cameras, Starlink at the house, a buried cable from the house to the barn. The installer set up port forwarding on a third-party router in bypass mode. It works on the farm Wi-Fi but not from town.

1. Check the router’s WAN address: 100.x.x.x. That’s CGNAT. Port forwarding can’t work.
2. Remove the port-forward rules and turn UPnP off. Open ports on a home router are a risk with no benefit here.
3. The NVR supports the maker’s cloud service. Turn it on and add the NVR in the phone app by QR code.
4. Test from the phone on cellular. Live view works. Playback of recorded clips is slower: it depends on the farm’s upload. See how many cameras the farm’s upload can handle.
5. Optional: install Tailscale on a small always-on computer in the barn as a backup path, in case the maker’s service has an outage.

Common mistakes

• Testing on the farm Wi-Fi. It works locally because you never leave the network. Always test on cellular data.
• Leaving old port forwards and UPnP on. They don’t help behind CGNAT, and if your connection ever gets a public IP, they expose the camera.
• Default passwords. Change them on every camera and NVR, whatever the remote-access method.
• Buying a local-only NVR system for a CGNAT farm without a plan. Check that it supports the maker’s cloud or can run alongside a mesh VPN.
• Blaming the bridge or the barn cable. If cameras work locally, the link to the barn is fine. Remote access is a separate problem.

What we don’t know

Camera makers change their apps and cloud features. Our compatibility notes come from each maker’s support pages, checked on the dates in the sources below, not from tests on a farm. We found no Ring or Arlo statement that port forwarding isn’t needed, so those rows are marked unverified even though both are cloud cameras. The owner-run camera tests behind a home CGNAT connection will be posted on the gear tests page and labeled as such.

Next step

Check your WAN address to confirm CGNAT. Then turn on your camera maker’s cloud or P2P feature and test from cellular. If your gear is local-only, follow the Tailscale steps in viewing cameras remotely behind CGNAT.