Messages

No, you cannot use RFC1918 in the destination of the IPv6 rule, because that cannot match any IPv6 address. You should use "any" as instructed.

That way, you will block any IPv6-related traffic, but since that is not needed for inter-VLAN traffic anyway, it does not block anything other than internet traffic from those MACs.

IDK how tapo actually works - maybe it can also find and connect to your cameras on your LAN, without using internet access. You can only find out by disconnecting your phone from WiFi and using your mobile connection. That way, you will come from "outside" your own network. If you cannot connect to your cameras this way, you can be sure that the cameras do not use cloud access.

Why we do that? Because in networking, everything is either true or false. When I see something that is false - especially when false advice is given - I correct it, nothing personal, you only take it for that. These topics are mostly security-relevant, so we should exercise some care.



So now for the OPs problem:

I understand AllInt is an interface group for all internal interfaces. OpnSense's rule processing order is documented here:

https://docs.opnsense.org/manual/firewall.html#processing-order

The order is floating rules > interface group rules > interface rules. Since your block rule is way up top in the interface group rules, it should work unless there were floating allow rules that allow outbound access.

How do you know that your cameras can still connect outside? Unless - I see you also have IPv6-related rules. Could it be the case that they open outbound connections via IPv6?

Your block rule only applies to IPv4, even if it incorrectly says IPv4+IPv6.

If that is your problem, you probably can block your devices only via their MAC - you would have to create a MAC alias containing both MACs and use that in a second IPv6 rule to block access to "any". You probably cannot use IPv6 aliases directly, if your IPv6 prefixes change.

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.

O.K., if that is pointless, I dare you to apply the following rule to your LAN interface (move it up to the top, because it "is pointless"):

You cannot view this attachment.

Then, try to ping 8.8.8.8 and see what happens.

Note that this is the very same rule the OP seems to use to block internet access for two devices, only that now it blocks all of your local IPs.

[WAN IP]

I do not confirm, you misunderstand source and destination. When any client with an RFC1918 IP connects to any IP on the internet, say 8.8.8.8, it will use OpnSense's WAN IP (which is routeable and unique) via NAT to go outside. That is what I wrote.

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.

You claim that this "cannot be done", which is false or "is unneccesary" - which I proved wrong in some cases, maybe not yours.

I also said that you can be safe by blocking specific devices from having internet access at all, but with the risk of losing (some, mostly cloud) functionality. The other approach is to separate your IoT network, allow those devices to have internet access, while risking them to spy inside your network, but then be limited to the IoT VLAN only, where they can do no harm. Neither of these approaches can be achieved by your average home router.

And I repeat: If you trust your IoT devices not to do any harm and also trust the capabilities of their manufacturers to defend their infrastructure, you can leave it as is.

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?

Then you need to show your rules in detail. What exactly is AllInt? Your LAN interface, an interface group or what?

What are the rules than are cut away in your screendump?

[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).

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

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

Your rule should do this, do not worry.

[can]

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:

What 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?

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.

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.

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.

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.

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.

Yes: Kea won't notice the change, AFAICS. Besides that, if the prefix changes and even if you got Kea DHCP to hand it out henceforth, your devices will only notice when the lease expires and they request a prolongation.

Maybe you should take a look at SLAAC and this howto. By using SLAAC, you will immediately notify clients to use the new prefix when it changes.

Ich würde abweichend vom oben Geschriebenen empfehlen, den neuen ONT (egal, ob extern oder SFP-Modul) mit der selben Seriennummer und dem selben PLOAM-Passwort zu konfigurieren, wie das Original. Dann bedarf es beim ISP keiner Aktivierung, egal, ob man die über ein Kundenportal oder über einen Support-Anruf erledigen muss.

Die Möglichkeit, den ONT ggf. on-the-fly zu wechseln, finde ich nämlich interessant.

Man braucht dazu nur zwei Dinge:

1. Die Möglichkeit, auf die IP des ONT am WAN-Interface zuzugreifen. Ist hier erklärt, Punkt 11.
2. Eine Anleitung, wie man an die notwendigen Daten herankommt oder diese ändert. Das findet man meist auf Hack GPON.

Es gibt auch etliche Threads hier im Forum dazu.

You should never be forced to configure anything besides using the GUI - if you need to, you are basically taking the wrong approach.

Use the official docs, where these basics are explained, your specific topic is explained here. Do not use youtube videos, as they are often half-baked, to say the least.

As for your network adapters: You are using the "dream combination" of problematic devices: One is a Realtek NIC and one a USB adapter. Throw a WLAN adapter in the mix and you finally have all three types of adapters that are badly supported on OpnSense. Take a look at https://forum.opnsense.org/index.php?topic=42985.0, points 6 and 7 for an explanation.

You can check the outbound DNS requests by using a tcpdump on the WAN interface for UDP port 53 and see who and what it being asked to get an idea of what it can be.

For Kea, there are only the options available in the web UI. You could use "Manual config", but then the whole configuration file must be created manually.

When you look on Github for these issues, you will find that for Kea, there probably will be no generic custom options. The preferred way to handle additional options with Kea is to add them one by one when the need arises, so you can make a feature request.

Other than that, your other option is to use DNSmasq for the DHCP server, where there exists a generic mechanism for options.