Hi. I am using your pihole container. I also have a question about pihole configuration for different network segments, where pihole is a common dns. The pihole is located at 192.168.8.15, I have vlans set up, 192.168.17.0/24, 192.168.18.0/24, 192.168.19.0/24, and they all recognize the names on the pihole 192.168.8.15, but in the pihole activity logs I don’t see any addresses other than the gateway address on the WAN which is 192.168.8.1. How do I reconfigure pihole/dhcp/network to register all hosts separately?
I understand the issue you’re facing with Pi-hole logging only the gateway’s IP address instead of the individual addresses from your VLANs. This typically happens due to NAT (Network Address Translation) applied to DNS queries by your router or gateway. To resolve this and get Pi-hole to log the actual source IPs of each query, you’ll need to disable NAT for these DNS queries. Here’s how you can do it:
- Access Your Router/Gateway Settings: Start by logging into your router or gateway’s administrative interface. This is usually done through a web browser.
- Locate NAT or DNS Settings: Look for sections in your router’s settings related to NAT or DNS. Your goal is to adjust how DNS traffic is handled.
- Modify DNS Handling Rules:
- If there’s an option for NAT rules, create a rule specifying that DNS queries directed to your Pi-hole’s IP (
192.168.8.15
) should bypass NAT. This might be labeled as “Do not NAT” or “Bypass NAT for the following”. - The key here is to ensure that DNS traffic retains its original source IP address, instead of being masked by the router’s IP.
- Check Network Routing: Make sure your network routes DNS queries from each VLAN correctly to the Pi-hole. This could involve setting static routes or adjusting firewall rules.
- Testing: After implementing these changes, generate DNS requests from devices on different VLANs and verify in your Pi-hole logs if the individual device IPs are being logged.
Keep in mind that router configurations can vary, so the exact steps might differ based on your specific model and firmware. If your router doesn’t support these types of NAT modifications, you might need to consider alternative network configurations or different hardware.
By doing this, Pi-hole should start logging DNS queries with the true source IP addresses, giving you a more accurate view of your network activity.
I hope this helps! Let me know if you have any further questions.
Thank you, for the answer and explanation of the principle of operation. I am working on Mikrotik, the rule I created in ip/firewall/nat is:
/ip firewall nat
add action=dst-nat chain=dstnat comment=“DNS to Pi-hole” dst-port=53 protocol=udp to-addresses=192.168.8.15 to-ports=53
add action=dst-nat chain=dstnat comment=“DNS to Pi-hole” dst-port=53 protocol=tcp to-addresses=192.168.8.15 to-ports=53
I placed it at the very top of the NAT rules, before the lan masquerade. Unfortunately, still no pi-hole does not register host addresses from other VLAN subnets.
Try:
Set Pi-hole as the DNS Server in DHCP Settings
- Navigate to
IP
→DHCP Server
→Networks
. - For each DHCP network (or each VLAN if they’re separated), set the
DNS Servers
field to the IP address of your Pi-hole (e.g., 192.168.8.15). - This ensures that all clients receiving an IP from the DHCP server will use Pi-hole as their DNS server.
2. Disable NAT for DNS Traffic to Pi-hole
- Go to
IP
→Firewall
→NAT
. - You might have existing NAT rules that masquerade outbound traffic or redirect DNS requests. Identify any rules that are masquerading or redirecting DNS traffic (port 53) and modify them to exclude traffic destined for your Pi-hole.
- A typical approach is to add a rule at the top of the NAT rules that accepts DNS traffic to the Pi-hole and bypasses further NAT processing. It would look something like this (adjust the IP address as per your setup):
/ip firewall nat
add action=accept chain=dstnat dst-address=192.168.8.15 dst-port=53 protocol=udp
add action=accept chain=dstnat dst-address=192.168.8.15 dst-port=53 protocol=tcp
Hi. Thank you for your help, it works well for a simple setup, however, I have a host spot deployed on the other segment of the network. Entering your configuration has no effect. Pi-Hole only lists the primary gateway.
Awesome, glad I was able to help. Now you have a more complicated setup.
Review Hotspot DNS Configuration
- Ensure the hotspot is configured to use Pi-hole as its DNS server. This might require adjusting the hotspot’s specific settings to point directly to the Pi-hole IP (192.168.8.15) for DNS resolution.
- If the hotspot service is providing DHCP, verify that it’s distributing the correct DNS server address (your Pi-hole) to connected clients.
Adjust MikroTik Firewall and NAT Settings
Given the complexity of your setup, it’s crucial to ensure that DNS requests from the hotspot and other VLANs are not being masqueraded before reaching Pi-hole, which would cause them to appear as coming from the gateway.
- Create a No-NAT Rule for DNS Traffic to Pi-hole: Make sure your no-NAT rule for DNS traffic to Pi-hole is correctly set up to apply to all VLANs and the hotspot network. The rule should precede any masquerade or other NAT rules that could alter the source IP of packets.
Example:
/ip firewall nat
add action=accept chain=srcnat src-address=[VLAN_and_Hotspot_Subnets] dst-address=192.168.8.15 dst-port=53 protocol=udp
add action=accept chain=srcnat src-address=[VLAN_and_Hotspot_Subnets] dst-address=192.168.8.15 dst-port=53 protocol=tcp
Replace [VLAN_and_Hotspot_Subnets]
with the actual subnet addresses of your VLANs and hotspot network. This tells the MikroTik router to bypass NAT (masquerading) for DNS requests heading to Pi-hole, retaining the original source IP address.
- Review Masquerade Rules: Ensure that the masquerade rules do not apply to traffic destined for Pi-hole. This might involve adjusting the source or destination addresses in the masquerade rule to exclude DNS requests to Pi-hole.
Debugging and Verification
- Log Packet Flow: Use MikroTik’s packet flow features to log and analyze the path that DNS requests are taking through the router. This can help identify where the requests are being NATed or if they’re reaching Pi-hole with the original source IP intact.
- Use Tools for Monitoring: Utilize tools like
tcpdump
on Pi-hole to monitor incoming DNS requests and verify their source IP addresses. This can help confirm whether the issue is on the router’s configuration or further upstream.
Thank you very much, for all your help. In my case, the network masquerade was solved by the orders. I have multiple network segments, and the rule only contained the external eth without the ip address they are supposed to present themselves with, and the external address of the router was falling into the pihole. Here is the correct entry:
/ip firewall nat
add action=accept chain=dstnat comment="Pi-hole -DNS" dst-address=172.20.0.15 \
dst-port=53 protocol=tcp src-address-list=SieciLAN
add action=accept chain=dstnat comment="Pi-hole -DNS" dst-address=172.20.0.15 \
dst-port=53 protocol=udp src-address-list=SieciLAN
add action=src-nat chain=srcnat comment=masquerade out-interface=\
sfp-sfpplus1-out-TSU to-addresses=111.222.333.444
172.20.0.15 - pi-hole serv