How to remote access CCTV's device behind CGNAT for IPv4, and device doesn't have support for DDNS IPv6?

Question

This question was originally asked in networkengineering.stackexchange and suggested to be moved here.

TL;DR

Multiple locations with local CCTV. How to remote access all of them, with an ISP that services IPv4 behind CGNAT and the DVR doesn't supports DDNS for IPv6. DVR also offers API, SDK, P2P and PPPoE:

1. API: Needs an HTTP connection to make the calls, CGNAT on the way.

2. SDK: Not sure how to leverage the SDK. Maybe I can embed software in the DVR, but don't know how to do it or where to start.

3. P2P: Don't know how to reproduce this connection. Also, it probably only allows live footage, which I already have with RTSP.

4. PPPoE: Not sure if it is even related to the problem.

5. Possible solutions that I was recently made aware and I'm still researching:

   a. IPv6 to IPv4 tunneling

   b. Is it possible to config a VPN just for the cameras/DVR traffic?

---

Intro

My family owns a local business that have 2 stores and a warehouse. They all have CCTV footage locally stored. I'm developing a side project for me to access those images remotelly, process them in a ML model and raise more relevant alarms.

I have a limited knowledge in computer networks, but my understanding is:

1. For all the locations, the ISP services us with IPv4 behind a CGNAT, meaning my public IPv4 is not only "mine".
2. I was able to access the live feed of the cameras using RTSP protocol with IPv4, by configuring port forwarding in the local router (of each location) for port 554. AFAIK this shouldn't be possible behind the CGNAT. The delay is sometimes ok (~2 sec) and sometimes awful (~20sec).
3. I've tried configuring port forwarding of ports 80, 8080, 37777 and 443 so I could be able to access the DVR interface remotely. That didn't work, I got either ERR_CONECTION_TIMED_OUT or ERR_EMPTY_RESPONSE. I've tried all these ports just to be sure, but internally in the network I can access the DVR interface by accessing http://192.168.15.93:8080, so just port 8080 should be enough. (Yes, I'm using the public IP when trying to access from outside the network)

My understanding is that I can't access the DVR interface because of the CGNAT, but shouldn't that also mean that the RTSP should also fail?

Problem

I'm exploring solutions beyond getting a static IPv4.

I don't want to process all cameras 24/7 through RTSP, for a number of reasons: bandwidth consumption, cost of executing the model 24/7 * {nr of cameras}, large delays with RTSP (probably caused by network conditions?), etc

I managed to get API docs and SDK for the DVR. I will be honest and say that I have no idea what to do with the SDK, as most of my programming has been for online platforms. I suppose that it's for embedding the software in the DVR or Cameras? I'd love to do that, but have no idea where to start.

With the API I can listen to the events the camera's raises, so I can process images only when there are events. However I can't reach the DVR remotely because of the CGNAT. I could, in theory do it through IPv6, but it's a dynamic IP and that means I'd have to reconfigure every time it changes. The DVR supports DDNS, but apparently only for IPv4.

Finally, there are two other types of connection supported by the DVR:

• One is called P2P, I can use the camera's APP to connect to it so I can see footage, but I don't know how to reproduce this connection so I can retrieve the image myself and process it. Not sure if this allows me to reach the API though.
• The second is PPPoE, which I also don't know how it works, and a quick google fu didn't help. It may not be related to the problem at all.

Note: Read somewhere about ipv6 to ipv4 tunneling, still reading about it, unsure if this is the right path.

Question

How can I connect remotely to my DVR if it's behing a CGNAT in IPv4, and IPv6 doesn't have DDNS support (in the DVR)?

Ideally I'm looking for a solution that runs remotely and not running locally on each location. (Besides the DVRs, obviously)

Answer 1

There is more then one way of solving this, but the one I would consider is building a VPN network.

I'd start by getting a VM with a cloud provider and running a VPN server on it (I'd choose OpenVPN or more likely Wireguard). I'd then run VPN clients on each of the routers to connect to the VPN server (this may require new routers that support VPN's).

Note that you don't need to route all traffic over the VPN - you can limit it to other VPN clients. Unfortunately this is not trivial to set up - but it can work very well while increasing overall security and, done correctly, allows direct access to cameras through VPN connected devices.

An easier but more expensive solution would be to forgo the VPN server and buy VPN clients from a provider that offers static IPs - you would need a static for each router, would need to set up port mapping, and would not have the security of the above solution.

Answer 2

To elaborate on my comment: To connect a network that is subject to CGNAT to a VPN, you need to establish the connection “from the inside”: A device on the network has to establish and maintain the VPN tunnel. If the router is capable enough, it could indeed do the job. However, more often than not, it cannot. This is not a deal-breaker though: Another device can do it, too! This is what I call “local gateway” in my comment. It need not be powerful or expensive. A Raspberry Pi could easily do the job. Depending on the bandwidth requirements, even the original Raspberry Pi could do the job! Though I’d recommend a recent model, of course, if you decide to go that route.

A dedicated local gateway should have a static IP address, either via configuration or via DHCP reservation.

If the router can’t do it, there are two major ways this could go:

1. You can enter a static route (via the VPN client device) to the VPN network on your router and it just works. Static local IP address required.

2. You cannot enter a static route or it just won’t work or a static local IP address is out of the question. More NAT to the rescue!

Either way, in addition to the on-site device on one end of the tunnel, you also need the other end: A device with a static internet IP address. A cheap virtual private server (VPS) does the job. (Alternatively, you could also go for something like Tailscale, though this is unlikely to work with an existing router.)

Case 1 is relatively easy: You set up your favorite VPN (WireGuard, OpenVPN, SoftEther, whatever; maybe even IPsec if you truly really absolutely want to). The VPN uses a subnet that is not in use in any other location. When using a “local gateway” device (not the default gateway), you set up a route on the default gateway (the “internet router”) to the VPN subnet via the respective client device.

Case 2 starts the same: Favorite VPN, “local gateway”. But then if the route refuses to work or cannot be set up or static IPs are not possible, more NAT could help! Just how a NAT router hides the whole network behind it and pretends all the traffic originates from the router itself, a “local VPN gateway” can pretend all the traffic from the VPN originates from itself. No routes required. Assuming Linux, this could be as simple as:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

If a static IP address is set up, a more sophisticated solution could be:

iptables -t nat -A POSTROUTING -o eth0 -j SNAT --to-source 1.2.3.4

…where 1.2.3.4 is the static local IP address and eth0 the sole Ethernet interface. Either way, you must make sure that iptables rules are restored on boot, in case of a power outage or simply updates. Different Linux distributions have different methods for that.

You can then connect to the VPN from anywhere and access any site almost as if you were there.