IP camera remote access over LTE: port forwarding that scales

You commissioned the machine, the cameras ping happily on the shop LAN, and the office cannot pull a single frame. The reflex is to open one port per camera - RTSP here, the web UI there - and it works until the carrier rotates the address or a scanner finds port 554 open to the world. This guide gives you the decision and the numbers behind it: why a single site-to-site tunnel beats a stack of port forwards on cellular, how many megabits per second four 1080p streams really need, which one port stays open, and the eight steps from key pair to a stream that plays in the office.

Should every camera get its own port forward, or is one tunnel enough?

One tunnel is enough: terminate a single site-to-site VPN on the LTE router or the on-site controller, open exactly one UDP port (WireGuard's default 51820), and reach every camera, controller and switch on the machine's LAN through it. No per-camera forwards at all, and the arithmetic is one-sided. Four cameras behind one router means eight or more forwarded services - RTSP and HTTP per camera, plus remote desktop on the controller - and eight rules to re-audit at every firmware update. A tunnel is one rule, one key pair per device, and exactly one service reachable from the internet; everything else on the machine LAN stays unroutable from outside.

The same decision governs PLC remote access, where forwarding the Modbus port fails the same way; the comparison in VPN versus port 502 forwarding for PLC remote access works through it in detail. For NAT symptoms on a wired router, the closer read is IP camera behind an industrial router: NAT and RTSP fixes.

Why does port forwarding fail on most LTE carriers?

Because the carrier usually puts the router behind carrier-grade NAT. The WAN address on the router is a private CG-NAT address in 100.64.0.0/10, not a routable public IP, so a port forward has nothing to forward - inbound packets never reach your router. The test takes two minutes. Read the WAN address on the router's status page, then query a what-is-my-IP service from any device behind it: two different addresses means CG-NAT, and no forwarding table on that router will help.

The second problem is rotation. Carriers hand out dynamic public addresses that change between hours and weeks, so even a working forward dies without warning. Dynamic DNS papers over rotation only when the address is truly public; behind CG-NAT it resolves to the carrier's gateway, not to your router. The two reliable designs are a SIM plan with a static public IP, or an outbound-only tunnel to a hub you control - and the outbound tunnel needs no special SIM at all.

An HMI on the same router hits the same wall; the HMI port forwarding failures note shows the diagnosis from the panel side.

How much uplink bandwidth do your camera streams need?

Budget 2-4 Mbps per 1080p H.264 main stream at 15-25 fps, roughly half that with H.265, and multiply by a 1.2 headroom factor: four cameras then need 4 x 3 x 1.2 = 14.4 Mbps of measured uplink.

Worked example: four 1080p cameras, H.264 main streams at 3 Mbps each, uplink measured at the cabinet 10 Mbps. The budget gives 4 x 3 x 1.2 = 14.4 Mbps, which is 4.4 Mbps more than the link delivers, so streams stall as soon as all four are watched at once. Move two cameras to H.265 substreams at 0.5 Mbps: (2 x 3 + 2 x 0.5) x 1.2 = 8.4 Mbps, which fits under 10 with 16% margin. Keep MJPEG off the cellular link entirely - a 1080p MJPEG stream runs past 10 Mbps on its own.

This budget covers viewing only. The acquisition frames from the machine's area scan cameras never cross the cellular link: the on-site controller pulls GigE Vision and USB3 Vision frames over the machine LAN, and what travels remotely is the encoded viewing stream, snapshots and inspection results. Sizing acquisition for many heads is a LAN problem - multi-camera system design for reliable image capture covers the capture side - and the interface choice behind it is in machine vision connectivity standards: what each one does.

How do you set the tunnel up, step by step?

The working pattern is outbound-only: a hub with a public IP (your office server or a small cloud VM) accepts the tunnel, and the LTE site dials out to it, so carrier NAT never has to let anything in.

1. Confirm the WAN situation. Compare the router's WAN address with a public-IP lookup from a LAN device: identical means a public IP, different means CG-NAT and an outbound-only design.
2. Choose the hub. An office server or small cloud VM with a public IP holds the tunnel; open exactly one UDP port inbound - 51820 for WireGuard or 1194 for OpenVPN.
3. Generate one key pair per device, on that device. A private key never leaves the machine it was created on and never travels by e-mail or ticket.
4. Configure the site peer: endpoint is the hub's public address and port, persistent keepalive 25 s, plus the route that sends the camera subnet into the tunnel.
5. Configure the hub peer for the site: accept the site's tunnel address and camera subnet - for example 10.99.99.2/32 and 192.168.10.0/24, illustrative addresses you replace with any private ranges that do not collide with your sites.
6. Set the tunnel MTU to 1420. If large transfers stall, apply tunnel MTU = path MTU - 80; a carrier path that passes 1440-byte packets gives 1440 - 80 = 1360.
7. Test in order: handshake counters increase on both peers, then a ping to a camera's LAN address through the tunnel, then the RTSP URL in your office viewer.
8. Delete every WAN port forward left from earlier attempts, and switch off UPnP on the cellular router so nothing re-opens ports by itself.

Subnet routing is where most first attempts go wrong; access a smart camera over VPN: add a remote subnet route walks the route table on the receiving side.

Which ports stay open, and which stay closed?

On the cellular side, exactly one port stays open: the tunnel's UDP port (51820 for WireGuard, 1194 for OpenVPN). RTSP 554, camera web UI 80 and 443, and ONVIF discovery on UDP 3702 stay closed at the WAN.

With a confirmed static public IP and a single camera, one hardened forward is defensible for occasional viewing. Two devices or a dynamic address, and the tunnel wins on every count: fewer exposed services, no rules to re-do after rotation, and one place to audit.

How do you keep the tunnel alive when the carrier rotates your address?

The tunnel survives address rotation because the site dials out and refreshes its own route. Set persistent keepalive to 25 s on the site peer so every rotation re-registers within 25 s, and never point anything at the site's WAN address. The 25 s keepalive is not cosmetic - it refreshes the NAT mappings at both the carrier gateway and the hub firewall, so the tunnel re-anchors itself with no client action.

Monitor it from the hub: WireGuard re-keys a live session about every 2 minutes, so a healthy site peer shows a fresh handshake inside 3 minutes (180 s); alert when none arrives past that. If the carrier sells a static public IP SIM, you can flip the design - the router becomes the server, one UDP forward, office and controller dial in - and the same closed-port rules otherwise apply.

Which controller hosts the cameras and the tunnel?

Put the cameras and the tunnel on the same industrial controller. The machine's vision controller already has the camera LAN on its own ports, so the tunnel terminates one hop from the cameras and no extra box rides in the cabinet. One box then does three jobs - acquire, inspect, hold the tunnel peer - and separation comes from ports rather than from extra hardware: camera LAN on its own port, tunnel and PLC traffic on the others. PoE camera ports power the heads over the same cable, which removes the injector budget; camera power over Ethernet: check support and alternatives lists the checks before you commit to that.

A tunnel interface also adds another IPv4 address to a multi-port machine, which is exactly the situation in UDP broadcast discovery fails with multiple IPv4 addresses - read it when discovery gets flaky after the tunnel comes up.

For a multi-camera cell with lights to drive, the vision controllers selection below carries the printed port counts to filter on: the MV-VC5525-256G70-NN has 5+ LAN ports, PoE camera ports, 8 built-in light channels and 32 GB of memory on an Intel Core i5.

For a compact single machine, the MV-VC2140-128G40-1T carries 3-4 LAN ports and 4 built-in light channels on an Intel N-series processor.

Either box runs the tunnel client alongside the inspection software, and the tunnel itself adds no measurable memory load - size for the vision application first. To turn the camera list and stream plan into a parts list, start at the system configurator.

What do you check before you close the cabinet door?

Run the six checks below at the cabinet, not from your desk: measured uplink at the antenna, WAN-versus-public-IP comparison, handshake both ways, a 1332-byte do-not-fragment ping through the tunnel, an RTSP stream from the office, and zero WAN forwards left open.

• Uplink measured with the cabinet closed and antennas mounted, at 1.2 times the stream budget - 8.4 Mbps in the worked example.
• WAN address equals the public-IP lookup, or the outbound-only design is confirmed on paper before handover.
• Handshake counters increase on hub and site, and a healthy peer re-handshakes about every 2 minutes.
• A do-not-fragment ping through the tunnel passes at 1332 bytes of payload - the 1360 tunnel MTU minus 28 bytes of IP and ICMP headers.
• The RTSP URL plays in the office viewer through the tunnel and survives 10 minutes without a stall; stalls after a restart usually trace to session timeouts, which diagnosing camera stream restart timeouts covers.
• The router's WAN forwarding table is empty, UPnP is off, and the only service reachable from the internet is the hub's single UDP port.

Keep the design honest at handover: one port open, one tunnel, every camera service LAN-only. To have the hosting box sized and quoted, send the camera list and stream plan through the contact page; the rest of the remote-access and networking notes sit on the systems topic page.