Blocked that hard-coded google dns garbage.
this post was submitted on 08 Nov 2023
226 points (97.9% liked)
Selfhosted
40329 readers
393 users here now
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
- awesome-selfhosted software
- awesome-sysadmin resources
- Self-Hosted Podcast from Jupiter Broadcasting
Any issues on the community? Report it using the report flag.
Questions? DM the mods!
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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 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.