Messages

meyergru, the football keeps on being moved a bit at a time. Eventually you will sneak it across the goal if nobody notices the sneak.

Shut Down the app - check

Block specific addresses from the lan- check

Conflating RFC1918 with errant devices - check

Internet Leakage - still an unsolved mystery

Everything else is only sneaking the football down the pitch. Why do you old pros always do that? All it does is chase people away. OK, you remain one of the princes here who apparently could use a refresher course in networking fundamental along with making an effort to stop changing the subject a little at a time so you are never wrong. That's annoying and not uncommon. I doubt you're fooling anyone except the other princes.  Don't argue with me like I'm your wife.

Now, fix his problem. Don't walk away after all this. I mean fix it, not offer some incomplete techno-babble.

Here's an overkill solution. Build a new subnet using an open port. (Please dear god ignore the VLANs. they aren't needed and won't add value.)  Hang a spare access point off of it or off of a simple switch attached to it. Put the bad devices on that subnet. Block the subnet from the WAN. Weirdly complicated and massive overkill, but fixed. My favorite solution is simply to unplug it.

meyergru, said: "If you do not want that, you can block specific source LAN IPs to access the internet (=destination !RFC1918), which is what the OP tried to do. If he failed in that, there must be something wrong with his rules, the order of processing or anything."

The rule blocks a nonroutable ip address. A pointless exercise.

The rest of what you wrote makes it appear you are unclear about what I wrote as it does not correlate to what I said, and not for the first time.

This time really leaving the chat, which has also become a pointless exercise.

[do]

RFC1918 IPs do go out over the internet if they are on your LAN and a NAT rule exists via the WAN IP - this is the default for any OpnSense installation as for LAN, there is a default "allow any -> any" rule and an automatic NAT rule for the WAN. If this were not so, you would not have internet access from your LAN.

And you still do not get what the firewall rule of the OP does: It is an "in" rule on (presumably) the LAN interface, which essentially blocks all outbound access for the cameras (as source) - the ONLY reason that in the destination, RFC1918 is exempted is to still allow local access (by virtue of the (presumably) existing "allow any" rule that comes further down in the list, but is not shown).

Stop the presses. OPNsense by default allows all local traffic to escape to the internet for all to see. Only a select few have firewall rules to prevent this.

That's what you just wrote. If it's true then I will immediately replace my Chinese router pcs with  my spare TP-Link ER605-V2 and be safe once again. Please confirm.

Quick question: How does the internet differentiate my 192.168.1.xxx from yours or anyone else's? There must be millions to choose from all across the world with the same local IP address? Or is my leaked data just floating in the ozone? Again - look up NAT and SPI, they work hand in glove to separate the local network from the outside world. Except possibly in OPNsense, according to you.

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?

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

coffeecup25 exits the group chat.

[If]

@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.

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.

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?

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.

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.

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.

how 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.

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.

cookiemonster,

Oh where to begin.

For an old pro, I notice you did not catch the double nat problem in the original post. It stood out like a blinking red light. 90% of the post was unnecessary to describe the problem, although it implied other issues.

Yes, I know the difference between a 'subnet' and a 2nd network. It's common - very very common - to use the terms interchangeably. Only a small minority of people get confused like you did.

Running a subnet out of an open port into a simple switch is common common common. I do it and it works perfectly. My IOT network comes off of it. I used to use a smart switch to break up LAN but the switch became unstable, as reported earlier, and I went the subnet route. Very simple and very stable. (The switch probably needed a firmware update is my guess.)  And, just in case you think you found a gotcha - LAN goes to a different simple switch than IOT. Both on the same simple switch would mean they share a broadcast domain and no amount of rule making on the router would separate the traffic.

If I had used a smart switch for the 2nd network it would have been utterly ridiculous. Makes no sense since 2nd network / subnet did the job already.

I know subnet math, or at least did when I took basic networking over a decade ago. Most people, I assume, learn it, admire how clever it is, and then forget it unless they go to work for a major corp with a giant network.

I see the old pros still like to run an exclusive club. What a shame. The real problem is perfect newbies to networking can't tell the difference and swaggering old pros shine the brightest, for better or worse.

drosophilia,
So, if I understand you, my best option is to spin up the Kea DHCP server in OPNsense and port my DHCP configuration and MAC address binding tables to it. Then either demote or replace my Cisco RV325 small business router with a switch since it is no longer supported or receiving updates.  Question, does ONPsense replace the need for using  PiHole? It has been a wonderful addition to my network for years now and I immediately notice it's absence whenever I am not on my home network. I would still like to have the DHCP server point to PiHole as a pre-fiter if ONPsense does not keep updated advertising block lists.

Adguard Home is a standard feature. It's also a DNS blocker like pihole. Using it inside of OPNsense is generally preferable because it's one less point of failure, as you can see first hand from the experience you documented above. Adguard Home is not the adblocking feature in Unbound, which is far less flexible.

Virtual IP is new to me. I have never even heard the term before reading this. Google says they are fairly common, sort of.

Like most things in Google, they provide a lot of information up to a point. Then nothing.

I found how to set them up. Lots of people offer information on that.

Nobody offers a simple explanation of what they are used for. What is the use case? Why would somebody want one and what would it do? Without using lots of jargon.

You are double natting. You are not getting DNS resolution in that configuration because pihole can not work properly.

Here's a little background education, pardon me for being presumptuous.

A 'Firewall' is more a marketing term than anything else. A firewall, by my definition, is a router with extra layers of software that does this and that to protect the network. 'This and that' being technical terms. 99.5% of everyone or more only needs one router active at any given time at a location.

In the network world you have routers and switches. Only. Retail routers are a combo router and switch, often with a wifi component. The Chinese router / pc with 4 or 6 ports becomes a router with a WAN and LAN port when you load OPNsense. The remaining ports are just sitting there until configured to do something. I've read that the extra ports are best for subnetting and not as VLANs because these boxes make poor switches compared to dedicated switches. The ports may look the same but they are not the same. Each subnet is a separate network and needs to go to its own dedicated switch and / or wireless access point.

Routers carry traffic between networks. Switches carry traffic on a network and they are designed for heavy traffic. Most of what happens on a network is confined to the switch and only goes to the router if it needs to jump to another network or possibly to renew a lease.

VLANs segment a broadcast domain on a smart / managed switch so one subnet can create privacy zones. Normally, everything on the switch can access everything in the same broadcast domain. VLANs break it up. The managed / smart switch manages the VLAN entirely. It has always been this way. The VLAN capability in OPNsense, pfSense, and whatever is clever but more confusing than helpful as the extra ports are said to make bad switches as they are not designed for traffic that heavy. Unlike a retail router that is a deliberate mix of router and switch. You do not need to create a VLAN on the router to use a VLAN on a smart switch. Even a used retail router with wifi from a thrift shop can work with the VLAN on the smart switch properly as soon as you plug it in and configure it as a router.

So, decide on Cisco or OPNsense and it should work perfectly.

I've been out of IT for a long time. Your description brought back memories from those days. Back then it was common for IT 'pros' to group together like mean girls. Sad but true. You were one of them in lockstep or you were at risk of being talked about behind your back in harmful ways and being shunned if they could get away with it. I don't know if things are still the same, only with different technology, but I hope they are better today. Their loss.