Messages

[in place of]

petski,

You are taking a simple situation and overcomplicating it by a lot.

That switch is overkill for what you have described. A $15 TP-Link dumb switch would have been better. Do a factory reset on the Cisco switch to turn it back into a dumb switch and leave it as a dumb switch. Do not do DHCP on it. Ever.

Use Kea DHCP and Unbound DNS. Google for how to set up Unbound. Unbound will be a fallback DNS server. KEA is fairly simple to use now that it does not have hidden boxes for simple config options.

Use the DNS override box on KEA to access Pihole. Find a box associated with your LAN interface where it asks for DNS servers. It will probably have 192.168.1.1 if 192.168.1.1 is your router address. Put the static address for pihole in that box in place of 192.168.1.1.

I am assuming all devices are on the same LAN. If you have more than one subnet, then I don't know if KEA can point to a pihole server on a different home subnet. Probably not. Look into Adguard Home instead, but you will have to edit AdguardHome.yaml to add all the local subnets it needs to serve.

I had planned to end my time here so you kids have an exclusive playground. But, you got me. Hopefully nobody else will draw me back again.

I just watched all the packets that escaped from your network and now I know all your secrets. I guess you were right. I can't get into your system since it uses non-routable addresses. But somehow your frames and packets (inside joke) found their way to me of all people.

Seriously. Reddit has normal people on the OPNsense forum. What's wrong with you and the other little princes?

Why not explain how your 192.168.x.x or whatever gets out and gets into trouble? Without using NAT and SPI, which is the traditional way traffic goes from a network to a destination and finds it's way back. NAT and SPI are actual firewalls. Look up NAT / SPI and your hesitation and apprehensions about Internet Leakage might lessen.

Mull this over .... why does the real pro or the prince need to write a rule to prevent Internet Leakage, while almost nobody has even heard of this terrible situation? Why isn't it an OPNsense default? Millions of routers are out there without any owner or manufacturer awareness. This should become yours and that other's guy's crusade to wake everyone up. Hopefully, this will be my last post here.

At least you will still have the newbies to impress.

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.