I think the solution is to avoid tech that you don’t control. Its a hard pill to swallow for some but at the end of the day there are tons of ways a device could bypass networking restrictions
I have a firewall rule to dst-nat any outgoing DNS requests not coming from piHole back to the piHole server. That way all devices on the LAN are forced to use piHole for DNS and can’t bypass it.
I don’t have an OPNSense firewall but I would think it should be able to do that as well.
I’ve blocked outgoing port 53 udp/tcp for all subnet except pi-hole. If I can’t trust a device to use the DNS I configured I can’t trust it to go on the internet, and it goes on my list of devices to replace.
I’ve been having some issues with random IoT devices bypassing my pihole despite it being a router-level DNS for all my devices. Can you go into more detail about dst-nat and how I might be able to improve catching requests so they can routed to pihole for filtering? My router is running openwrt and pihole is on a VM in my hypervisor that’s directly connected to the router. This is the first time I’m hearing about dst-nat.
Your router is, at it’s core, a very advanced traffic cop and NAT – Network Address Translation – is it’s primary function. You have multiple devices on your local network (LAN) that need to communicate with other non-local servers via the WAN (i.e. the internet).
Now you have a problem. Your ISP assigns you (usually) a single IP address on their network which is on a different subnet than your LAN. Devices on your local network and devices on the WAN are not aware of one another and cannot communicate with each other directly. So, requests have to be routed to the correct destination via your router.
SRC-NAT
Let’s say you’re trying to pull up a website on your computer. Your computer sends the request to the router. Your router alters the IP packet headers so that the request source address, and therefore the address that the server responds to, is your WAN IP instead of the requesting devices LAN IP. Your router then forwards the packet to the destination server, tracks the connection, and forwards the response back to your computer.
DST-NAT
Let’s say you’re hosting a web service on your home server that you want to make available publicly. You would set up a dst-nat (often called port forwarding) rule in your router/firewall which will tell your router to redirect any requests received at the WAN IP on port 80 or 443 to your home server’s IP address. Unlike SRC-NAT, your router doesn’t replace the source IP address. Just the destination. Your server knows that the requesting device is not on your LAN subnet and will forward the response back to the gateway (your router) which is already tracking the connection and will forward the response back to the requesting device via the WAN.
Routing DNS with DST-NAT
Since DST-NAT is just changing the destination IP address and routing the packet to the new destination, this can be done internally in some situations as well. To redirect DNS requests, you would set up a rule in your router/firewall to grab outbound UDP packets that originated from the LAN, do not originate from your internal dns server, and have a destination of port 53 and redirect/dst-nat them to the IP address of your choice. The new destination can be an internal or external IP address and the requesting device won’t know the request was redirected.
OpenWRT’s documentation actually has a section that deals with DNS redirection which you can find here. The DNS redirection part is near the bottom of the page.
That’s correct. I block DoT in my firewall and block known DoH domains in piHole. I’m sure stuff slips through occasionally but the vast majority of my DNS requests are handled by piHole.
Traditional DNS over UDP/53 is insecure but I’m using ProtonVPN’s DNS server over VPN externally so I’m not worried about that.
How do you block the DoH servers in the pihole? Pihole is a DNS server, devices using a third party DoH server would just bypass the pihole as they’re using the IP of the DoH with no DNS lookup required. No?
To block DoH I think you need to block it at the firewall level with a list of blocked IPs for the DoH servers you want to block over 443
You’re probably better off blocking it at the firewall level. It would be more thorough but also more effort. In my experience, most devices/apps that use DoH call a domain name rather than an IP. If you block the domain in piHole, the app cant resolve the DoH server IP and therefore won’t be able to use DoH.
Yeah you’d need an L7 application layer filtering firewall to catch DoH since it would detect the SSL packet signature on port 53. Unfortunately that balloons the cost of the device past a reasonable level for a home aficionado.
A workaround for now would be to block known public servers that use DoH like Google DNS, since a lot of devices are adding features to enable DoH by default at the OS level
I configured my Asus router with asuswrt-merlin firmware to route all DNS traffics to my Adguard instance to catch those apps and devices with hard-coded DNS. Those routed DNS queries appear in adguard as originating from my router’s IP address, so I can easily see what apps and devices trying to bypass my dns. Turns out the main offender is Netflix.
My router doesn’t log the target dns server ip address, but according to many forum threads, netflix apps seems to hardcode the dns to 8.8.8.8 and 8.8.4.4.
Hey man, can you share some resources that you followed to configure Opnsense as VM. I am in the same situation, bought a firewall, that I want to use as a hypervisor but didn’t configure yet the Opnsense and would love to educate myself more on the matter.
Not familiar with Rokus, but it depends on what your filtering. Mostly it’s to block needless analytics tracking. I use a pair of PiHoles for much the same purpose.
One reason used to be to switch to a different region for Netflix, etc but I’m not sure if that still works, I haven’t had to use a Roku in a long time.
Using the firewall to force dns because the services were stupid enough to rely on dns to determine location. You would use a (usually paid) dns service hosted out of the wherever the content you want was and get access to region locked stuff like the US netflix library from abroad. This worked because vpns were being detected and rokus dns was hard coded so assumed to be trusted.
I don’t know if this still works because I no longer own anything Roku and Netflix’s service hasn’t been worth that kind of shenanigans for a long time. It likely doesn’t work anymore.
Interesting. I set an adblocking dns via DHCP and, as far as I know, the Roku respects it. Ads are blocked and I can see it failing to delivery telemetry in my dns logs (most persistent thing on the network).
I set a rule to catch outside dns to see if anything, the roku included, has been misbehaving.
Pihole blocks the basics for Roku. Things like logs ads etc. but there’s a lot more telemetry that they’re collecting. Here’s a hackernews thread about the topic and the associated article it references.
You are not logged in. However you can subscribe from another Fediverse account, for example Lemmy or Mastodon. To do this, paste the following into the search field of your instance: !selfhosted@lemmy.world
A place to share alternatives to popular online services that can be self-hosted without giving up privacy or locking you into a service you don’t control.
Rules:
Be civil: we’re here to support and learn from one another. Insults won’t be tolerated. Flame wars are frowned upon.
No spam posting.
Posts have to be centered around self-hosting. There are other communities for discussing hardware or home computing. If it’s not obvious why your post topic revolves around selfhosting, please include details to make it clear.
Don’t duplicate the full text of your blog or github here. Just post the link for folks to click.
Submission headline should match the article title (don’t cherry-pick information from the title to fit your agenda).
No trolling.
Resources:
selfh.st Newsletter and index of selfhosted software and apps
I do a DNS redirect on my Mikrotik router.
It’s going to suck when DoH and DoT becomes more prevalent.
Best you can do is maintain a list of public DoH IPs and block them. Redirect all port 53 traffic to your own DNS server.
I think the solution is to avoid tech that you don’t control. Its a hard pill to swallow for some but at the end of the day there are tons of ways a device could bypass networking restrictions
+1 for dst nat on googles dns servers back to my piholes
Acronyms, initialisms, abbreviations, contractions, and other phrases which expand to something larger, that I’ve seen in this thread:
[Thread #267 for this sub, first seen 8th Nov 2023, 04:10] [FAQ] [Full list] [Contact] [Source code]
Good bot
I have a firewall rule to dst-nat any outgoing DNS requests not coming from piHole back to the piHole server. That way all devices on the LAN are forced to use piHole for DNS and can’t bypass it. I don’t have an OPNSense firewall but I would think it should be able to do that as well.
I’ve blocked outgoing port 53 udp/tcp for all subnet except pi-hole. If I can’t trust a device to use the DNS I configured I can’t trust it to go on the internet, and it goes on my list of devices to replace.
I’ve been having some issues with random IoT devices bypassing my pihole despite it being a router-level DNS for all my devices. Can you go into more detail about dst-nat and how I might be able to improve catching requests so they can routed to pihole for filtering? My router is running openwrt and pihole is on a VM in my hypervisor that’s directly connected to the router. This is the first time I’m hearing about dst-nat.
NAT TLDR
Your router is, at it’s core, a very advanced traffic cop and NAT – Network Address Translation – is it’s primary function. You have multiple devices on your local network (LAN) that need to communicate with other non-local servers via the WAN (i.e. the internet). Now you have a problem. Your ISP assigns you (usually) a single IP address on their network which is on a different subnet than your LAN. Devices on your local network and devices on the WAN are not aware of one another and cannot communicate with each other directly. So, requests have to be routed to the correct destination via your router.
SRC-NAT
Let’s say you’re trying to pull up a website on your computer. Your computer sends the request to the router. Your router alters the IP packet headers so that the request source address, and therefore the address that the server responds to, is your WAN IP instead of the requesting devices LAN IP. Your router then forwards the packet to the destination server, tracks the connection, and forwards the response back to your computer.
DST-NAT
Let’s say you’re hosting a web service on your home server that you want to make available publicly. You would set up a dst-nat (often called port forwarding) rule in your router/firewall which will tell your router to redirect any requests received at the WAN IP on port 80 or 443 to your home server’s IP address. Unlike SRC-NAT, your router doesn’t replace the source IP address. Just the destination. Your server knows that the requesting device is not on your LAN subnet and will forward the response back to the gateway (your router) which is already tracking the connection and will forward the response back to the requesting device via the WAN.
Routing DNS with DST-NAT
Since DST-NAT is just changing the destination IP address and routing the packet to the new destination, this can be done internally in some situations as well. To redirect DNS requests, you would set up a rule in your router/firewall to grab outbound UDP packets that originated from the LAN, do not originate from your internal dns server, and have a destination of port 53 and redirect/dst-nat them to the IP address of your choice. The new destination can be an internal or external IP address and the requesting device won’t know the request was redirected. OpenWRT’s documentation actually has a section that deals with DNS redirection which you can find here. The DNS redirection part is near the bottom of the page.
I suspect DoT and DoH still go through, though? I mean you can always block the port 853 for DoT, but DoH is another story.
That’s correct. I block DoT in my firewall and block known DoH domains in piHole. I’m sure stuff slips through occasionally but the vast majority of my DNS requests are handled by piHole.
Traditional DNS over UDP/53 is insecure but I’m using ProtonVPN’s DNS server over VPN externally so I’m not worried about that.
I see. I may try to do something similar but towards Unbound on my OPNSense router, if that’s possible.
How do you block the DoH servers in the pihole? Pihole is a DNS server, devices using a third party DoH server would just bypass the pihole as they’re using the IP of the DoH with no DNS lookup required. No?
To block DoH I think you need to block it at the firewall level with a list of blocked IPs for the DoH servers you want to block over 443
You’re probably better off blocking it at the firewall level. It would be more thorough but also more effort. In my experience, most devices/apps that use DoH call a domain name rather than an IP. If you block the domain in piHole, the app cant resolve the DoH server IP and therefore won’t be able to use DoH.
Yeah you’d need an L7 application layer filtering firewall to catch DoH since it would detect the SSL packet signature on port 53. Unfortunately that balloons the cost of the device past a reasonable level for a home aficionado.
A workaround for now would be to block known public servers that use DoH like Google DNS, since a lot of devices are adding features to enable DoH by default at the OS level
I configured my Asus router with asuswrt-merlin firmware to route all DNS traffics to my Adguard instance to catch those apps and devices with hard-coded DNS. Those routed DNS queries appear in adguard as originating from my router’s IP address, so I can easily see what apps and devices trying to bypass my dns. Turns out the main offender is Netflix.
That’s interesting. What IP address is netflix hardcoding?
My router doesn’t log the target dns server ip address, but according to many forum threads, netflix apps seems to hardcode the dns to
8.8.8.8and8.8.4.4.Hey man, can you share some resources that you followed to configure Opnsense as VM. I am in the same situation, bought a firewall, that I want to use as a hypervisor but didn’t configure yet the Opnsense and would love to educate myself more on the matter.
I’m currently using this guide to setup a OPNsense VM on proxmox. Home Network Guy also has an OPNsense guide, but for a full router.
Thanks for the link but in the series I can only find information about Pfsense and not Opnsense.
It’s pretty similar, but I combined those two guides and that worked pretty well.
Is this to block ads?
Not familiar with Rokus, but it depends on what your filtering. Mostly it’s to block needless analytics tracking. I use a pair of PiHoles for much the same purpose.
One reason used to be to switch to a different region for Netflix, etc but I’m not sure if that still works, I haven’t had to use a Roku in a long time.
How would you switch regions using a firewall?
Using the firewall to force dns because the services were stupid enough to rely on dns to determine location. You would use a (usually paid) dns service hosted out of the wherever the content you want was and get access to region locked stuff like the US netflix library from abroad. This worked because vpns were being detected and rokus dns was hard coded so assumed to be trusted.
I don’t know if this still works because I no longer own anything Roku and Netflix’s service hasn’t been worth that kind of shenanigans for a long time. It likely doesn’t work anymore.
Edit: Unblock-US used to be such a service
No, you can block ads with a pihole. This is because Roku hard codes its dns server as 8.8.8.8. Pihole doesn’t handle IP addresses, only DNS.
Interesting. I set an adblocking dns via DHCP and, as far as I know, the Roku respects it. Ads are blocked and I can see it failing to delivery telemetry in my dns logs (most persistent thing on the network).
I set a rule to catch outside dns to see if anything, the roku included, has been misbehaving.
I doubt it but could this help my tv randomly crashing
It’s genuinely so annoying and is such a 2023 problem
Tv crashing? Add an external device and don’t use TVs for their smart features as they tend to be pretty bad.
Some days I miss my old LG Plasma. Sold the house and left it bolted to the wall. 1080P, deep blacks, crisp colors, and zero “smart” features.
It put off enough heat to warm up the living room but that was only a “bug” in the summer months. Simpler times.
Pihole blocks the basics for Roku. Things like logs ads etc. but there’s a lot more telemetry that they’re collecting. Here’s a hackernews thread about the topic and the associated article it references.
Well, I’m back and can confirm the sneaky DNS resolver. I have two roku devices and they both were making requests to 8.8.8.8.
Thanks for this post! TIL.
TIL that dns uses udp instead of tcp
https://www.geeksforgeeks.org/why-does-dns-use-udp-and-not-tcp/
One more confusion: If DNSSEC is enabled it actually switches to TCP, since DNSSEC requires messages that are much bigger than what UDP can transfer.
I setup a NAT rule that redirects anything going to the Google DNS IP’s send sends it to my own DNS server.
I did that for anything on port 53.
I can’t recall if I limited to Google’s IP’s or not actually. Just that I wanted to prevent their devices from ignoring the DHCP provided hosts