block cameras to internet

Started by robertkwild, December 17, 2025, 02:32:06 PM

Previous topic - Next topic
hi all,

made a rule to block cameras to the internet as i dont want to manage on the cloud anymore as i have a local NVR set up

this is my rule

https://postimg.cc/kBq4V72N

and these are my aliases

rfc1918
<content>10.0.0.0/8
172.16.0.0/12
192.168.0.0/16</content>

cameras
<content>10.100.1.249
10.100.1.250</content>

and there def the ips as when i stream them via vlc i see the streams

am i doing something stupid

thanks,
rob

December 17, 2025, 03:29:50 PM #1 Last Edit: December 17, 2025, 03:37:32 PM by coffeecup25
There's a good chance I am missing the point entirely, but you may be doing something unnecessary.

The RFC1918 addresses are non-routable by design. This system allows you, me and the man behind the tree to all have 192.168.1.1/24 subnets without crashing into each other. The three ranges normally are associated with various sized networks, with the 192.168.x.x ranges for home networks by convention. Nothing prevents a home network from using one of the other ranges.

Find out the app that's sending the videos outside of your home and shut it down.

https://netbeez.net/blog/rfc1918/

I googled this. It seems to be a good definition.

That is mostly incorrect.

While it is true that RFC1918 IPs are not routed outside of the local network, the problem is that by virtue of NAT rules on your firewall, those IPs will usually be translated to the routeable WAN IP and then go out to the cloud. So, if you want to prevent outside (i.e. cloud) access, you absolutely need to act to prevent that.

By having that rule on the LAN interfaces, any non-local IPs (i.e. !RFC1918) are blocked before they are handled by outbound NAT.
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

how would i then go about blocking those cameras off the internet then please?

Quote from: robertkwild on December 17, 2025, 03:51:58 PMhow would i then go about blocking those cameras off the internet then please?

The cameras aren't acting on their own. An app is controlling them. Find the app and shut it down. Or google it to find out the app's specs. See how it is communicating and shut that down. The RFC1918 rule is blocking something that never happens.

December 17, 2025, 04:26:17 PM #5 Last Edit: December 17, 2025, 04:38:06 PM by coffeecup25
Quote from: meyergru on December 17, 2025, 03:39:58 PMThat is mostly incorrect.

While it is true that RFC1918 IPs are not routed outside of the local network, the problem is that by virtue of NAT rules on your firewall, those IPs will usually be translated to the routeable WAN IP and then go out to the cloud. So, if you want to prevent outside (i.e. cloud) access, you absolutely need to act to prevent that.

By having that rule on the LAN interfaces, any non-local IPs (i.e. !RFC1918) are blocked before they are handled by outbound NAT.


What are those IPs translated to so they can go out onto the WAN? Where does my 192.168.1.xxx visit when I'm not watching it? It doesn't leak like air from a balloon as raw data drifting off to the cloud along with everyone else's raw data. Can you provide an example or three as literally billions of people are currently affected by the problem you describe. Virtually nobody anywhere writes rules like that.  Only a select few, according to what I found on google. That belief is either the biggest secret that everyone should know in the world and router companies should include by default into every router in the world,  or a large misconception.

A few specific examples that would appear everyday to the billions affected should put the matter to rest. I would certainly love to learn something new if it is this important. But I need use cases, not suspicions. If I'm wrong, then I'm wrong. The people who are never wrong are the people who never do anything.

Please don't confuse SPI with Internet Leakage.

but surely there on my LAN and using those ips i gave to you guys ie 10.100.1.249 and 250 as i can see the leases on my dhcp?

December 17, 2025, 04:42:28 PM #7 Last Edit: December 17, 2025, 04:52:09 PM by coffeecup25
Quote from: robertkwild on December 17, 2025, 04:30:20 PMbut surely there on my LAN and using those ips i gave to you guys ie 10.100.1.249 and 250 as i can see the leases on my dhcp?

DHCP deals with local addressing. Of course you can see all the devices on your network on DHCP. What is your specific concern?

Just a thought, but the internet has numerous free intro to networking courses and texts available. All of your concerns are included in the early chapters.

Also, networking is networking. Different companies sometimes implement the universal concepts differently. Cisco and OPNsense and TP-Link, and all the other big companies all do things 'their way' but all use the same networking concepts. DHCP is the same everywhere, but each router company may implement it differently if they consider it appropriate.

December 17, 2025, 04:59:00 PM #8 Last Edit: December 17, 2025, 05:19:40 PM by meyergru
Many cameras (and other IoT devices, for that matter) open connections to their respective clouds by themselves - without any app.

There is a simple reason why they do this: Because most home routers by default allow outbound connections, while they block inbound connections. Otherwise, the user must open a port to allow viewing from the internet via a browser or an app. Also: how should the app find the device without dyndns - if that is even possible with a CG-NAT/DS-Lite connection?

If you trust your IoT device's manufacturers, you can just ignore this, but what if you don't?

Why do you think so many of us put "non-trusted" devices into separate VLANs where they are allowed to have internet access to fulfill their service, while on the other hand, they can do no harm, because access from the IoT VLAN to the LAN can be forbidden? That is the whole point where tools like OpnSense are better than your average home router.

Are you remotely aware how any of this works, like, e.g. that any IP connection can be used both ways, once it is established?

And to answer your basic questions:

Quote from: coffeecup25 on December 17, 2025, 04:26:17 PMWhat are those IPs translated to so they can go out onto the WAN?

I already said that: They are NATed to your WAN IP. You can try for yourself: Use a browser on your PC (which has an RFC1918 IP) and call up https://whatismyipaddress.com/ - the IPv4 address you see is your WAN IP, so how is that working? Your PC does not have that IP, right? And the packets were routed on the internet to that site, right? So it actually can be done, right?

Quote from: coffeecup25 on December 17, 2025, 04:26:17 PMWhere does my 192.168.1.xxx visit when I'm not watching it? It doesn't leak like air from a balloon as raw data drifting off to the cloud along with everyone else's raw data.

I already said that: It can (note: it does not have to) connect to its specific cloud where the manufacturer's app goes to when accessing your cameras.

Quote from: coffeecup25 on December 17, 2025, 04:26:17 PMCan you provide an example or three as literally billions of people are currently affected by the problem you describe. Virtually nobody anywhere writes rules like that.  Only a select few, according to what I found on google. That belief is either the biggest secret that everyone should know in the world and router companies should include by default into every router in the world,  or a large misconception.

A few specific examples that would appear everyday to the billions affected should put the matter to rest. I would certainly love to learn something new if it is this important. But I need use cases, not suspicions. If I'm wrong, then I'm wrong. The people who are never wrong are the people who never do anything.

Please don't confuse SPI with Internet Leakage.

I gave an example and boy, are you wrong...

P.S.: I have a friend who is using two UpCams. They are thought to be made by a german company: https://www.upcam.de/ (currently, their website certificate is expired, which makes this even more comical now).

I was quite amused to see outbound connections from these cameras to the Alibaba cloud, where the cloud services are hosted. Turned out that the cameras where made in China, and only branded to different OEM's needs, as indicated my the MAC belonging to "Shenzhen Ogemray Technology Co.,Ltd". When you visit their site, you will see that they provide a "One-stop product and service cloud platform".

Goes to show how these devices can be as cheap as they are.
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

December 17, 2025, 05:12:28 PM #9 Last Edit: December 17, 2025, 05:30:09 PM by coffeecup25
meyergru,

No, I called every shot correctly.

My TAPO doorbell and light bulbs and various cameras all use the TAPO App to communicate with TP-Link. They do not have minds of their own like little AI Terminators. I even have them on their own subnet (no VLANs anywhere). Very private on my network. If I want them to stop communicating with TP-Link, then I disconnect them from my local lan and they go silent. They will also probably stop working. My thermostat, on the same IOT subnet, works without a connection to the home office. When it is connected, I can change the temperature while never leaving my recliner - from anywhere in the world. the TP-Link TAPO app allows world wide access. So there's that.

Moral and absolute rule every time - turn off the app if you don't want it to go out over the internet. The little terminators may fume but a doorbell can't cause much harm without an internet or lan connection.

Putting non trusted apps or non-trusted people on separate networks, or separate broadcast domains using a VLAN, has ABSOLUTELY NOTHING to do with RFC1918.

NAT and SPI don't works as you think they do. Seriously, look it up. you will be embarrassed. But, as I said, the only people who don't make mistakes are the people who don't do anything. So good for you for putting yourself out there. So many 'experts' only lurk behind the scene and undermine those who do things.

So, back to the original  poster. Shut down the app and you will end your concerns automatically. or block the ip assigned from DHCP from outgoing traffic. But first assign a fixed local ip otherwise it may get a new number after the lease expires.

December 17, 2025, 05:20:56 PM #10 Last Edit: December 17, 2025, 06:04:50 PM by meyergru
Quote from: robertkwild on December 17, 2025, 03:51:58 PMhow would i then go about blocking those cameras off the internet then please?

Your rule should do this, do not worry.
Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

@coffecup25: Your cameras and selected IoT devices may do that. Where does the OP say he uses exactly those devices?

The OP expressed concern and wanted to make sure his cameras do not connect outside - and he successfully achieved that goal by his firewall rule.

Besides that: If you can use your camera app from outside of your network, I can absolutely, 100% assure you that the cameras connect outside without your app started or active or you having asked for a cloud connection - if not for a standing connection, your app could not reach your cameras inside your home network in the first place. So, who would then tell your cameras to connect outside? See? BTW: This was exactly the case with my friend's UpCams.

Please note - I do not say YOUR cameras do this. I only say, SOME (if not most) do, so read the OP's request again in that light.

Intel N100, 4* I226-V, 2* 82559, 16 GByte, 500 GByte NVME, ZTE F6005

1100 down / 800 up, Bufferbloat A+

but trouble is my rule doesnt work and i dont understand why it doesnt work, i dont get how its going out even tho ive created a rule for it, do i need to create an outbound NAT rule aswell?

Quote from: meyergru on December 17, 2025, 05:27:55 PM@coffecup25: Your cameras and selected IoT devices may do that. Where does the OP say he uses exactly those devices?

The OP expressed concern and wanted to make sure his cameras do not connect outside - and he successfully achieved that goal by his firewall rule.

Besides that: If you can use your camera app from outside of your network, I can absolutely, 100% assure you that the cameras connect outside without your app started or active or you having asked for a cloud connection - if not for a standing connection, your app could not reach your cameras inside your home network in the first place. So, who would then tell your cameras to connect outside? See? BTW: This was exactly the case with my friend's UpCams.

Please note - I do not say YOUR cameras do this. I only say, SOME (if not most) do, so read the OP's request again in that light.



As RFC1918 states, non-routable addresses do not go out over the internet, so there's no need to block them from the WAN. I covered this in detail above. Anyone who wants to do a little intro to networking research can easily confirm this.

Agree nothing can connect to the internet without a standing connection. Also my point above in excruciating detail.

December 17, 2025, 05:35:18 PM #14 Last Edit: December 17, 2025, 05:36:57 PM by coffeecup25
Quote from: robertkwild on December 17, 2025, 05:32:29 PMbut trouble is my rule doesnt work and i dont understand why it doesnt work, i dont get how its going out even tho ive created a rule for it, do i need to create an outbound NAT rule aswell?

I just explained why the rule does not work. More than once. What are you really asking?

coffeecup25 exits the group chat.