block cameras to internet

[meyergru]

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

[meyergru]

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?

[coffeecup25]

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.

[meyergru]

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.

[coffeecup25]

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.

[meyergru]

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.

[robertkwild]

heres my "allint" i have grouped all my local LAN interfaces

LAN_HOME - my tp link cameras sit here
DMZ
openvpn
wg1
wg0

heres my full set of rules

https://postimg.cc/3d9xSHDG

[coffeecup25]

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]

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.

[chemlud]

Hi, I see different problems with your BLOCK rule:

- You want to block ipv6 traffic for ipv4 adresses (in your cam alias)? What is the status for ipv6 on your LAN? Place a general block ipv6 above your block rule and reduce the existing block rule to ipv4 protocols.

- Do your cams get reserved (static mapping, always identical) IPs (based on MAC) via DHCP? Only in this case the block rule will block the cams reliably.

Cheers (noisy in here... hohoho)

[robertkwild]

i have no floating rules

changed the cameras alias from hosts to mac address and added the mac addresses of both cameras, applied the changes and still not working

the way im seeing them not working is i go on the tplink tapo app on phone and i can still see them connected so i know there still going on the internet

what ip address do i put in for ipv6 as they havnt got an ipv6 address, or have they?

ok heres my new rules

https://postimg.cc/ctGjQ7tr

so ive made one for ipv4 and one for ipv6, my ipv4 is camera ipv4 ips and ipv6 is camera mac addresses

[meyergru]

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.

[passeri]

@robertkwild, I have a corresponding setup, cameras talking to an NVR which is accessible from an app or local web address. The NVR is on a unique subnet where it is blocked entirely from the internet. It is allowed to request only the time, which is served by Opnsense, or of course respond to received requests. I can use the app to access the NVR because access from the primary subnet into the NVR subnet is not blocked (direction). Thus, if you have carried out meyergru's suggested test you should find you have access from within your network, not from outside it. If that is the case then all is well with your rules.

To view your cameras when away from home, set up wireguard access to home, allowing requests from that subnet into the NVR subnet.

I am unable to comment on your rules for a couple of reasons. One is that as a usual practice I do not click on external image addresses in here. More importantly, using remote images means that those images will eventually die, making the entire thread meaningless for future readers. Please always upload images or code here using the tools available. It also enables easier reading and responses.