Messages

danke für den Hinweis, verstanden 👍

Nein, Du hast es nicht verstanden. Man verwendet so gut wie nie ,,out" Regeln.

Der ausgehende Verkehr, den Du blockieren willst, kommt zuerst über das LAN Interface zur Firewall herein (,,in") und dort solltest Du ihn blockieren.

Da hatte ich schon viele, die das tun, z.B. von HP. Wenn man die lässt, melden sie den Verbrauch nach Hause, checken, ob Firmware-Updates vorliegen und bestellen Verbrauchsmaterial nach.

Die Firmware-Updates machen ggf. Third-Party-Cartridges unbrauchbar - habe deswegen gerade einen HP zurückgeschickt.

Am Rande nutzen sie Cloud-NTP-Server.

Der Nachfolger - ein Lexmark - ist nicht viel anders.

I always do such setups with WireGuard. One instance with two peers on each site. Each Site has routes to any of the other two. And in absence of a central DNS Server, I delegate the two remote domains to their respective DNS servers on each local Unbound Server.

I am not going to Show the Solution to this - Even if this was possible, I would Refrain from doing so.

Thankfully, things Like this are forbidden in Germany but:

I remember that in 1995 I implemented Internet Access for a Bank group when exactly this was requested by the auditing Department. I took the Time to teach them a lesson: I proceeded to discuss all the technical details on how this was to be done during a three hour Meeting. At the end of the Meeting, I told them IT would immediately start implementing it as soon as they presented a written consent by the works Council.

The Expression on their faces was priceless after recognizing that I meant that dead serious.

Read https://forum.opnsense.org/index.php?topic=42985.0 Point 5.

you can optionally secure those ports with 802.1X (best, but this is still broken in UniFi as reported by @meyergru).

Matter-of-fact, I got a beta version these days that ought to fix the 802.1x problem. It still does not, but reintroduced the "all VLANs are visible during bootstrap" problem. But at least it seems Ubiquiti is on it.

They are prioritized lower, but ULAs will not even be used for Internet access unless a NATed inbound connection is used first. And the priorization is about they target IP, which is a routeable IP, anyway.

You do not need them for outbound access at all - some people want to have IPv6 only and with dynamic prefixes, they do not have internal DNS. That is were ULA might be helpful. Then again, with dual stack, they will not be used when an IPv4 DNS entry exists.

Well, despite the warnings I use it mixed as well. But I also do not use any IDS that works with netmap.

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.