this post was submitted on 29 May 2025
11 points (100.0% liked)
Privacy
39018 readers
493 users here now
A place to discuss privacy and freedom in the digital world.
Privacy has become a very important issue in modern society, with companies and governments constantly abusing their power, more and more people are waking up to the importance of digital privacy.
In this community everyone is welcome to post links and discuss topics related to privacy.
Some Rules
- Posting a link to a website containing tracking isn't great, if contents of the website are behind a paywall maybe copy them into the post
- Don't promote proprietary software
- Try to keep things on topic
- If you have a question, please try searching for previous discussions, maybe it has already been answered
- Reposts are fine, but should have at least a couple of weeks in between so that the post can reach a new audience
- Be nice :)
Related communities
much thanks to @gary_host_laptop for the logo design :)
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
If you're worried about your IoT devices on your LAN the problem isn't necessarily that they can access WAN but rather that there's a security vulnerability and that they can be accessed by the WAN. Once a device is compromised and attacker can then use it as a "beachhead" to access other devices on your network.
So for example, with my setup every IoT device is on a separate VLAN (the guest network acts similarly) which can't get access to WAN, can't be accessed from the WAN and can't initiate any network calls to any other VLAN. Now my primary VLAN can talk to my IoT VLAN, and IoT can talk back, it just can't start the communication.
This does pose a problem for TVs though that need to talk to Jellyfin as hinted at in the original post. So what you could do is create a specific firewall rule that allows the TVs to at least initiate communication to Jellyfin but not any other device on your primary VLAN. This will probably require a more sophisticated router though than most of the consumer ones out there. Just be mindful that if n IoT device is compromised they can then try to attack the jellyfin server to jump to your other VLAN and then the rest of your network.
I don't understand your response. You're essentially doing the exact same thing I am. Preventing iot devices from accessing wan. The end result in the same, except you're blocking it from accessing other devices on lan as well. But access to wan is blocked which is the most important. If a device has a security vulnerability then by blocking wan access, you're blocking an attacker from getting in, unless someone malicious is already on your local network, which in that case you're fucked anyway. Apologies if i misunderstood your point.
With a Pihole, you aren't preventing the device from reaching the internet, you're just refusing to provide it answers to its DNS requests. That means that it can't translate a domain name (example.com) to an IP address (1.2.3.4) using your DNS server. But there's nothing stopping it from using a different DNS server whose IP it has hardcoded, and nothing stopping it from then talking to anything on the internet once it has the correct IP to use.
In contrast, the other poster sounds to be using a firewall to apply ACLs. That means that the only way to reach the WAN is by passing over the firewall, and the firewall can apply rules about what traffic it allows. That prevents the device talking to a hardcoded DNS server, or talking to something on the internet if it alreadt knows its IP.
The other poster also talks about adding specific exemptions to these ACLs for specific services. So, e.g. letting the TV reach Jellyfin, but only Jellyfin & not all the other devices on the network. That reduces the risk of an attacker using the IoT device as a way to attack the rest of the network, since there's less stuff to attack. You're right that this is a fairly marginal gain for an IoT device which doesn't have WAN access anyway.
The downside of this approach is that the device enforcing the ACLs has to handle all the network traffic. That means it needs more processing power to take packets, apply the ACL rules and then decide whether or not to send it onward. The upside of a Pihole is that DNS is a relatively tiny amount of traffic, so it takes much less processing power to handle just DNS.
So most alternative router firmware comes with a feature that can be configured to re-route any hard coded DNS through the pihole. I.e., my Smart TV will switch to Google DNS if it can't connect through your set DNS. The feature I mentioned will force this to always go through your configured DNS. This is completely solves that issue. I've thoroughly tested this and it 100% works. Also routers have a feature that can block a device from accessing the WAN at all, and only allow them to access the LAN. This is just a simple toggle in my router and extremely easy to use. I block certain devices that I don't want to have intentet at all but that I want to access over the network (i.e. plex)
Just to be clear, my goal with my setup is limiting tracking, telemetry, and ads.
Sure, but that's not the setup you described in the original post. I think that's probably where your confusion is coming from - people are responding about a setup that's just a PiHole, not a PiHole plus router features to ensure that it's used.
Ultimately any setup that allows the device internet access is going to introduce some opportunities for tracking/telemetry/ads. If the vendor really wants to they could just channel all that data through a single HTTPS connection, along with the useful data you want to let the device access. You won't have any way to inspect that traffic and selectively block it, so you end up having to chose between blocking everything or blocking nothing.
Your setup sounds like it's reaching the privacy/functionality trade off that you want.