Multiple Remote Location IPCams Setup

W

WS6Bandit

n3wb
Oct 23, 2025
1
0
Midwest, USA
Hello,

Long time lurker here finally registered and joined to further my knowledge. I've played with NVR/DVR systems for a few years now but now have a project that I need some help with. I have multiple construction sites I am trying to monitor and need a security camera solution. I am trying to setup multiple IP Cameras that are remote to connect to Blue Iris. I don't have to use Blue Iris but from what I've read and after playing with it, it seems to be a solid program. I have already purchased some equipment to try and setup but not having much luck. What I am trying to accomplish is using T-Mobile business internet w/ static IP's on my construction sites to connect to the IP cameras remote with Blue Iris. T-Mobile business internet uses a Inseego FX4100 Cellular router w/ a 5g connection and also provides me a static IP. I have a dedicated PC to run Blue Iris which is located at my main office. I plan on standing camera poles that will hold either 2 or 3 IP cameras. I am able to provide power to each camera pole as well. Each Pole will have its out Inseego FX4100 Cellular router from T-Mobile that has its own static IP. Each camera pole will also have a Unifi Switch Flex connected to the Inseego router that will provide POE power to the IP Cameras. Does anyone have any suggestions on how I can accomplish this with the equipment I have or do I need to look for different equipment. Example of my hierarchy below. Any suggestions or tips would be greatly appreciated as I have a lot of activity going on that I am trying to monitor.

  • Dedicated PC at Main Office W/ Blue Iris (Has its own static IP)
  • Construction Site 1
    • Camera Pole 1
      • Inseego FX 4100 Router 1 W/ Static IP
        • Unifi Switch Flex
          • IP Camera 1
          • IP Camera 2
    • Camera Pole 2
      • Inseego FX 4100 Router 2 W/ Static IP
        • Unifi Switch Flex
          • IP Camera 3
          • IP Camera 4
          • IP Camera 5
  • Construction Site 2
    • Camera Pole 3
      • Inseego FX 4100 Router 3 W/ Static IP
        • Unifi Switch Flex
          • IP Camera 6
          • IP Camera 7
  • Construction Site 3
    • Camera Pole 4
      • Inseego FX 4100 Router 4 W/ Static IP
        • Unifi Switch Flex
          • IP Camera 8
          • IP Camera 9
    • Camera Pole 5
      • Inseego FX 4100 Router 5 W/ Static IP
        • Unifi Switch Flex
          • IP Camera 10
          • IP Camera 11
          • IP Camera 12
  • And so on......
 
My comment: when you say "static IP" that means it doesn't change (not dynamic) but does not necessarily make it "public" (exposed to Internet). I mention this because most cellular ISP's employ CGNAT wherein the IP, whether static or dynamic for the WAN, is not public therefore not exposed to the Internet. You won't access the remote LAN via conventional means (like simple but NOT recommended port forwarding).

I believe that limitation can be overcome by using a VPN such as Zerotier or Wireguard running on a qualified router (like from GL.iNET ) at the site.
 
Last edited:
You could ( possibly) add a headache with a specific UniFi switch if it restricts you to the UniFi-verse of products/ devices to complete the connection circuit.
Not sure how Universal that device is.
A simple 4 port layer 2 POE switch might be more friendly to attach to the T-Mobile routers at the poles. that way any power interruptions will not require any input from you when power is restored.
There is a member here who has erected remote cellular camera setups in Nebraska and has posted on the forum.
I havent seen or heard from him in awhile though,
He could be a good resource.
I'm trudging thru the forum. seeing if I can find a post from him
 
TRLcam

Thread 'Livestream camera in the sandhills of Nebraska'

The Nebraska sandhills region covers roughly 23,000 square miles . It is a vast region of sparsely populated counties and not too many roads. It lies atop the Ogallala aquifer, the largest fresh water aquifer in the world. In the low lying areas are hundreds of lakes and rivers. 85% of the region is still in its natural state, never plowed. The University of Nebraska has a few research ranches in the region. The camera described below is set up on a hilltop that has cellular coverage most of the time. About ten years ago I installed three timelapse cameras on the research ranch. At...
  • Like
  • Wow
 
Looks like the Inseego FX4100 supports VPN protocols.

Setup a VPN server at your HQ, either on the BI PC or another PC / VM, or on your HQ firewall depending on the model. Configure each cellular router to dial an outbound VPN to the HQ - then it doesn't matter if their IP's are not truly public, or even if they are static or not.

Then configure BI to access the cameras via a local IP through the tunnels.
 
  • Like
Reactions: TonyR
Using a VPN would generally be the recommended way. However as noted, depending on your service provider and how they NAT/issue addresses to their customers, this may or may not be a workable solution.

Another option is to use a service like Tailscale to create your VPN connections. This would likely work even if you can't get normal static IP addresses from your service provider.

Yet another option (that I am trying to learn about, but am still much less familiar with) is to use IPv6 addresses. Since each device would have a unique IPv6 address (that isn't duplicated anywhere in the world), you can connect devices across the internet pretty easily. In theory, you would just enter the IPv6 address of your cameras in your NVR system and they would connect - even across the internet. Of course this assumes your networks and devices (cameras and NVR) support IPv6 addresses. My understanding is that BI does support IPv6 addresses. This solution doesn't require any NAT/port forwarding like IPv4 addresses do, so it is far more secure than using port forwarding on your firewall/router with IPv4 addresses.

EDIT - I initially said you would have to put in firewall rules to allow those IPv6 addresses through your firewall, but on second thought that is incorrect. Because BI would be initiating the communication with the remote cameras, the return data from the cameras would be allowed through the firewall/router just like any other returning data (like browsing a website). Therefore using IPv6 addresses like this is probably just as secure as using a self hosted VPN because there wouldn't be any open ports/addresses allowed through the firewall/router. Of course if you want remote access to the BI system, then you probably still want/need to use a self hosted VPN service. But if the primary concern is getting the remote cameras to communicate with a local BI instance, the IPv6 address solution would work just fine and be relatively simply to set up (once you wrap your mind around how IPv6 addresses work and make sure you local and remote networks work correctly with them).
 
Last edited:
  • Like
Reactions: TonyR
Not to be controversial, and I am by no means good at IPv6, but...

Because BI would be initiating the communication with the remote cameras, the return data from the cameras would be allowed through the firewall/router just like any other returning data (like browsing a website).
Click to expand...
OK, but this does mean firewall rules will be needed on the remote side (cameras) firewalls, to allow the BI traffic to get to the camera. Unless you have a really terrible firewall that passes inbound IPv6 by default (scary!).

This solution doesn't require any NAT/port forwarding like IPv4 addresses do, so it is far more secure than using port forwarding on your firewall/router with IPv4 addresses.
Click to expand...
And, I may be the one in the wrong here, but why is using IPv6 addresses (and using the correct firewall rules, otherwise it's not going to work), any more secure than using port-forwarding with IPv4 (and no, I don't advocate port forwarding, at least not to cameras).

A) All data would still be sent across the internet most likely in cleartext.
B) Poking holes in your IPv6 firewalls means your cameras are just as exposed as they would be if you used Port Forwards with IPv4. If you setup your firewall rules to only allow a specific source IPv6 (your BI machine), then that's basically equivalent to port forwarding an IPv4, and then using a firewall rule to control access to the port - better, but still not great...

People often treat NAT as a security measure with IPv4 - really it's not - you have the NAT layer to map many internal IP's to, usually 1 public IP, but then you have the same firewall layer to control access - with IPv6, the NAT layer is gone, but the firewall layer is the same.

However as noted, depending on your service provider and how they NAT/issue addresses to their customers, this may or may not be a workable solution.

Another option is to use a service like Tailscale to create your VPN connections. This would likely work even if you can't get normal static IP addresses from your service provider.
Click to expand...
To clarify 100% - if you are using a VPN solution, you likely only need a public / static IP on the VPN server side - E.G if you choose to run the VPN server at your HQ, you will need a publicly-routable (non CGNAT) IP there, but if the camera firewalls have CGNAT Ip's this is usually fine.

And if you cannot get a publicly routable IP at your HQ (E.G you have an annoying ISP), you can stand up a server somewhere else with a true public IP (or in the cloud), and use this as a VPN concentrator - both camera firewalls, and your HQ connect TO this server - thus the only component requiring a public IP is the central server. Tailscale is another option which can be simpler to setup, if you just cannot get publicly routable IPs at any of your sites at all.

Be careful! :)
 
EagleEye7 said:
Not to be controversial, and I am by no means good at IPv6, but...


OK, but this does mean firewall rules will be needed on the remote side (cameras) firewalls, to allow the BI traffic to get to the camera. Unless you have a really terrible firewall that passes inbound IPv6 by default (scary!).


And, I may be the one in the wrong here, but why is using IPv6 addresses (and using the correct firewall rules, otherwise it's not going to work), any more secure than using port-forwarding with IPv4 (and no, I don't advocate port forwarding, at least not to cameras).

A) All data would still be sent across the internet most likely in cleartext.
B) Poking holes in your IPv6 firewalls means your cameras are just as exposed as they would be if you used Port Forwards with IPv4. If you setup your firewall rules to only allow a specific source IPv6 (your BI machine), then that's basically equivalent to port forwarding an IPv4, and then using a firewall rule to control access to the port - better, but still not great...

People often treat NAT as a security measure with IPv4 - really it's not - you have the NAT layer to map many internal IP's to, usually 1 public IP, but then you have the same firewall layer to control access - with IPv6, the NAT layer is gone, but the firewall layer is the same.


To clarify 100% - if you are using a VPN solution, you likely only need a public / static IP on the VPN server side - E.G if you choose to run the VPN server at your HQ, you will need a publicly-routable (non CGNAT) IP there, but if the camera firewalls have CGNAT Ip's this is usually fine.

And if you cannot get a publicly routable IP at your HQ (E.G you have an annoying ISP), you can stand up a server somewhere else with a true public IP (or in the cloud), and use this as a VPN concentrator - both camera firewalls, and your HQ connect TO this server - thus the only component requiring a public IP is the central server. Tailscale is another option which can be simpler to setup, if you just cannot get publicly routable IPs at any of your sites at all.

Be careful! :)
Click to expand...

If the cameras have a firewall/router at the remote location, then yes it would require that the IPv6 address of the BI server be allowed through the firewall.

This is still more secure than using port forwarding with IPv4 addresses however. With IPv4 addresses, bots simply pick random IPv4 addresses (there are only 3,706,452,922 publicly available IPv4 addresses) and scan for the most often used ports to find ones that have been opened/port forwarded. This means that if they randomly picked your public IPv4 address to scan, they actually use a frightening small number of "attempts" before they might find something usable. Most bots scan about 1000 ports per address, but even a full scan is only 65,536 total ports.

There are 79 octillion times more IPv6 addresses than there are IPv4 addresses. This means that even if a bot randomly choose your IPv6 address to "scan", they would still need to come up with the entire 128bit IPv6 address that is being "let through the firewall" before they could start to find a vulnerability. There are 340,282,366,920,938,463,463,374,607,431,768,211,456 unique IPv6 addresses that a bot would have to try to work through to find the correct one. To put that into perspective even scanning a single /64 subnet at a 1 million address per second speed would take over 500,000 years to scan every address in that subnet. Most service providers typically assign residential customers a IPv6 /56 subnet to use. A /56 subnet is the size of 256 (two hundred and fifty six) /64 subnets which means that for a bot to scan just the /56 subnet that I have been assigned for my personal network would take 148,480,000 years at 1 million addresses per second. That's a far cry from only needing to scan 65,536 possible open ports.

TL/DR
If you port forward with an IPv4 address, a bot only needs to randomly choose your public IPv4 address (1 out of 3,706,452,922 public addresses out there) and then scan 65,536 ports to be guaranteed to find the unprotected port.

If you use an IPv6 public address, and let an IPv6 address through your firewall, a bot must randomly choose your public IPv6 address (1 out of 340,282,366,920,938,463,463,374,607,431,768,211,456 possible addresses) and then pick the correct 128 bit IPv6 address being let through (out of 340,282,366,920,938,463,463,374,607,431,768,211,455 possible IPv6 addresses it could be) before it would be guaranteed to find the unprotected address.

Even all of that being said, I specifically said that the most secure way to allow remote access would be through a VPN. But it is also clear that letting a IPv6 address through the firewall is considerably more secure than using simply port forwarding.
 
Last edited:
OK, from that perspective, I suppose one could consider it "more secure". Fair enough. Technically though the fact someone doesn't know the address is sort of security-by-obscurity...
 
EagleEye7 said:
OK, from that perspective, I suppose one could consider it "more secure". Fair enough. Technically though the fact someone doesn't know the address is sort of security-by-obscurity...
Click to expand...
I mean technically it is security by obscurity, but when we say that in IPv4 world it's usually talking about using a "random port" to open rather than using the default port of whatever service/software they are exposing. In that case it is a false sense of security because again bots only need to scan a maximum of 65,536 ports before they will find the open one. Using a random port might slow a bot down by a few minutes, but they are still going to find the vulnerability.

It's not a false sense of security when talking about IPv6 however. The numbers are so much larger that hackers don't even attempt to find or exploit things "randomly." They know that it could literally take hundreds of thousands of years to find an opening in just one network and therefore they don't even try. Instead they rely on other techniques (like social engineering) to get actionable information about the network they want to exploit before making any attempts.
 
You must log in or register to reply here.
Top Bottom