dhcp-option 6 not working on my AC68U

Discussion in 'Tomato Firmware' started by Nazgulled, Feb 28, 2019.

  1. Nazgulled

    Nazgulled Serious Server Member

    Hi,

    I'm using an old build of AdvancedTomato so I'm not sure if this is a bug that's probably fixed on newer versions of FreshTomato and or AndreDVJ's builds of "FreshAdvancedTomato".

    Thing is, I setup a Pi-Hole server and I've been trying to add the nameserver with "dhcp-option=6,PI_HOLE_SERVER_IP" but looking at /etc/resolv.conf shows "nameserver 127.0.0.1" and /etc/resolv.dnsmasq shows both Cloudflare nameservers (for both IPv6 and IPv4). In other words, the Pi-Hole nameserver doesn't seem to be used at all.

    Thoughts?
     
  2. Nazgulled

    Nazgulled Serious Server Member

    I looked at my "dnsmasq.conf" file and noticed this:

    Code:
    interface=br0
    dhcp-range=tag:br0,192.168.0.201,192.168.0.253,255.255.255.0,1440m
    dhcp-option=tag:br0,3,192.168.0.254
    So I added this option instead:

    Code:
    dhcp-option=tag:br0,6,PIHOLE_SERVER_IP
    It doesn't seem to work...

    Just in case, I tried to add this to my custom dnsmasq configuration:

    Code:
    interface=br0
    dhcp-range=tag:br0,192.168.0.201,192.168.0.253,255.255.255.0,1440m
    dhcp-option=tag:br0,3,192.168.0.254
    dhcp-option=tag:br0,6,PIHOLE_SERVER_IP
    Still didn't work. I noticed on my Windows PC (192.168.0.101) that my network connection add the PIHOLE_SERVER_IP in the DNS field but it doesn't seem to help. I still see stuff like this in my router's log:

    Code:
    Mar  1 13:30:05 AC68U daemon.info dnsmasq[20409]: 12 192.168.0.101/61185 query[A] play.google.com from 192.168.0.101
    Mar  1 13:30:05 AC68U daemon.info dnsmasq[20409]: 12 192.168.0.101/61185 forwarded play.google.com to 1.1.1.1
    Mar  1 13:30:05 AC68U daemon.info dnsmasq[20409]: 13 192.168.0.101/61834 query[AAAA] play.google.com from 192.168.0.101
    Mar  1 13:30:05 AC68U daemon.info dnsmasq[20409]: 13 192.168.0.101/61834 forwarded play.google.com to 1.1.1.1
    Mar  1 13:30:05 AC68U daemon.info dnsmasq[20409]: * 192.168.0.101/61185 dnssec-query[DS] google.com to 1.1.1.1
    Mar  1 13:30:05 AC68U daemon.info dnsmasq[20409]: * 192.168.0.101/61834 dnssec-query[DS] google.com to 1.1.1.1
    Mar  1 13:30:05 AC68U daemon.info dnsmasq[20409]: * 192.168.0.101/61185 reply google.com is no DS
    Mar  1 13:30:05 AC68U daemon.info dnsmasq[20409]: 12 192.168.0.101/61185 validation result is INSECURE
    Mar  1 13:30:05 AC68U daemon.info dnsmasq[20409]: 12 192.168.0.101/61185 reply play.google.com is 172.217.16.238
    Mar  1 13:30:05 AC68U daemon.info dnsmasq[20409]: * 192.168.0.101/61834 reply google.com is no DS
    Mar  1 13:30:05 AC68U daemon.info dnsmasq[20409]: 13 192.168.0.101/61834 validation result is INSECURE
    Mar  1 13:30:05 AC68U daemon.info dnsmasq[20409]: 13 192.168.0.101/61834 reply play.google.com is 2a00:1450:4003:809::200e
    
    It still goes through my static (Cloudflare) DNS servers, it completely skips my PIHOLE_SERVER_IP DNS server.

    Not sure which fork I'm using but I believe it's not the official one (from Jacky) since I think I updated this to a FreshTomato build with AdvancedTomato by AndreDVJ. That's the idea I have, I'm not sure, but:

    Code:
    Tomato Firmware 1.28.0000 -3.5-140 K26ARM USB AIO-64K
    Built on Sun, 19 Aug 2018 05:59:52 -0700
    
    Do you think this is a reconfiguration on my side or it could be some bug that I'm being affected due to the older build I'm using?
     
  3. Sean B.

    Sean B. Network Guru Member

    Considering you referenced resolv.conf and resolv.dnsmasq, implies you're speaking of DNS servers used by the router. Dhcp-option flags used in dnsmasq are configurations for the LAN clients of which receive DHCP information from dnsmasq, and obviously the router does not DHCP itself. The PI-hole DNS server IP should be placed under Basic->Network for the Static DNS if you want it used by processes running on the router.
     
  4. Nazgulled

    Nazgulled Serious Server Member

    That would be the typical way of doing it and it's described here as "method 1" but I was trying to configure my Pi-Hole/Router with "method 2" (described on the same link).
     
  5. Sean B.

    Sean B. Network Guru Member

    I didn't fully read it, but from what I did read they are not explaining it very well, boarder line incorrectly. You need to do both method 1 and method 2 if you want the router and LAN clients to use the PI-hole directly. In other words, if you just did method 1 and put the PI-Hole DNS server IP into the Static DNS box under Basic->Network what would happen is your LAN clients would send their DNS queries to the router/dnsmasq , but from there dnsmasq would be using the PI-hole as its upstream DNS server that it forwards queries to. So all clients on your network as well as the router itself will be getting their answers from the PI-hole via the router/dnsmasq. Setting method 2 by itself will configure all LAN clients to send their DNS queries to the PI-hole directly, however any DNS queries made from the router itself will not go to the PI-hole, rather they will go to the DNS servers handed down from your ISP ( or whatever other servers you have put in the Static DNS boxes ). Setting method 1 and 2 would have DNS queries made from the router itself go to your PI-hole, and also have LAN clients send their queries directly to the PI-hole bypassing the router/dnsmasq.

    **NOTE** To clarify, when I say "from the router itself" I am referring to any process that is running on the router. Such as dnsmasq, ntpd, nslookup run from a shell on the router etc.
     
    Last edited: Mar 2, 2019
  6. Nazgulled

    Nazgulled Serious Server Member

    @Sean B. I wouldn't mind if the router makes queries directly to my upstream DNS servers as long as all clients use Pi-Hole's DNS server instead. Those are the ones that matter, the clients are the ones that need to be filtered.

    Anyway, I think I have something wrongly configured on my router because I can't get my devices to use Pi-Hole's DNS server even when I manually configured each device to use it. I'm not sure what could be wrong but I flushed the DNS cache, I've reset my network connection and I even disabled IPv6 just in case. I try to search for stupid things on Google and open domains I never opened before just to be sure I don't hit some cache anyway but it doesn't work. All my DNS queries go to the router anyway, they seem to skip the "DNS Server" configuration.

    I tested this with my Windows PC (Ethernet) and Android device (Wi-Fi). Both have a LAN IP of 192.168.0.x, both have the gateway set to 192.168.0.254 (the router) but the DNS is set to 10.132.0.8 (more on this IP below).

    My Pi-Hole is installed on Google Cloud Platform and that is the internal IP address. I have my router configured as a VPN Client, connecting to my Google Cloud Platform VM instance (where Pi-Hole is installed) and I've pinged 10.132.0.8, both from the router itself (from an SSH connection) and from the devices themselves, and I got a response, I can even open Pi-Hole's admin interface on my LAN. In other words, I think the VPN Client is correctly configured and I can (or should) succesfully use Pi-Hole's VPN server.

    tl;dr;


    All DNS queries seem to go through the router itself and not Pi-Hole's DNS server, even when LAN clients are configured with static DNS server pointing to Pi-Hole's.
     
  7. Sean B.

    Sean B. Network Guru Member

    Verify you don't have the option "Intercept DNS" enabled under Advanced->DHCP/dns, it sounds as though you do.
     
    Nazgulled likes this.
  8. Nazgulled

    Nazgulled Serious Server Member

    I do have that enabled, is that what it does? I never understood correctly that option and after my research I left it enabled (it's been like that for a few years). So, just to be clear, that option intercepts DNS requests in the network and forces dnsmasq and/or the static upstream servers? Is that all it does?

    I'm not able to test everything right now but let me know if my thinking is correct or wrong:
    1. Configure Pi-Hole to use the upstream servers of my choice (Cloudflare).
    2. Disable "Intercept DNS port" under "Advanced » DHCP/DNS".
    3. Push Pi-Hole's DNS server to LAN clients with "dhcp-option=tag:br0,6,10.132.0.8" and to guest LAN clients with "dhcp-option=tag:br1,6,10.132.0.8".
      • br0 - LAN clients on 192.168.0.0/24 subnet.
      • br1- guest LAN clients on 172.16.0.0/24 subnet.
    4. Configure the router's static DNS servers under "Basic Settings » Network" too either Cloudflare's or Pi-Hole's too.
      • Since the main point of Pi-Hole is to filter ads by blocking certain domains, I guess there's really no need to enable that for requests out of the router itself, just the clients.
    5. With this setup, any client connected to my network, wired or wireless, guest or not, will use Pi-Hole's DNS server by default without extra configuration and Pi-Hole will be able to identify the client using it's server by hostname and not just by IP. Correct?
      • That step (in method 2 of the linked article above) of disabling all upstream DNS servers in Pi-Hole's configuration and only adding one - the router's internal IP - is simply pointless, right?
    I'll see if I'm able to do some testing on all of this tomorrow and report back.

    Thanks @Sean B.
     
  9. Monk E. Boy

    Monk E. Boy Network Guru Member

    Intercept DNS connects port 53/udp packets sent to the internet to dnsmasq instead of routing them out the WAN. Only someone who reads the source can say for sure exactly what it does, but in my experience it creates an iptable rule that forwards all outbound 53/udp traffic to the router's IP on 53/udp, which (normally) dnsmasq then answers.

    If I remember right there's a way of configuring Tomato to hand out option 6 to clients through the GUI in some builds. I think under LAN you can sometimes specify DNS servers for clients to use. But I believe this generates a config option only for the default br0 VLAN and doesn't touch the secondary br1 guest VLAN you've got, so you'd probably be stuck configuring guest under advanced/dhcp either way.
     
    Nazgulled likes this.
  10. Sean B.

    Sean B. Network Guru Member

    Yes, that's what it does. The "intercept DNS" option is designed to catch misconfigured or misbehaving programs running on LAN clients from circumventing the router as the DNS server. It will redirect any port 53 traffic ( UDP sense implemented, TCP as well in newer builds such as FreshTomato ) to the router instead, and from the client side everything will work normally except the IP address for the response will be the router instead of whatever DNS server is configured on the computer. Your dhcp-option line is working as it should, it's just being rendered ineffective due to the router intercepting the requests. Turning that option off should solve your problem.
     
    Nazgulled likes this.
  11. Nazgulled

    Nazgulled Serious Server Member

    It indeed solved my problem, thank you very much for all your help :)
     
  12. geekjock

    geekjock Network Guru Member

    My configuration, AC68U with FreshTomato plus OrangePi One with Pi-hole and Stubby DoT:

    Basic, Network, WAN Settings: DNS Server: Manual, DNS 1: Pi-Hole IPv4 address, DNS 2: 0.0.0.0
    Basic Network, LAN: Enable DNSSEC and other options: all unchecked, WINS: 0.0.0.0
    Basic, IPv6: Static DNS: Pi-Hole IPV6 address
    Advanced, DHCP/DNS: Intercept DNS Port: checked, all other DNS settings unselected
    Dnsmasq Custom configuration:
    dhcp-option=option:dns-server,Pi-Hole IPv4 address
    dhcp-option=option6:dns-server,[Pi-Hole IPv6 address]
    no-negcache
    log-async=25

    The above seem to be working perfectly for me. The dhcp-option commands instruct clients to send DNS queries directly to the Pi-hole. Note IPv6 address in square brackets. The router internal DNS is turned off ("Use internal DNS" unchecked), but rogue clients or apps with different DNS servers hardcoded, will be intercepted and sent to the Pi-hole.

    YMMV with different firmware.
     
  13. Sean B.

    Sean B. Network Guru Member

    Your Pi-hole DNS server is within the same subnet as the LAN clients which use it then. Link local traffic is not routed, switches pass the traffic without the router ever seeing it, as such your router never has the chance to intercept it. Remember that a router is comprised of two devices, the CPU ( which does the routing ) and a 4 port switch ( with some extra, purpose specific internal ports ). In @Nazgulled's case, his Pi-hole is in a different network segment and therefor traffic between it and the LAN clients is routed, resulting in the DNS interception.
     
  14. geekjock

    geekjock Network Guru Member

    Ah, thanks for the clarification. Full disclosure, I am not a Network Guru, despite linksysinfo.org.

    As an aside, I have two VLANs set up on my router, and clients from both show up on my Pi-hole.
     
  15. Sean B.

    Sean B. Network Guru Member

    Are you certain the clients on the VLAN of which the Pi-Hole is not a part of are receiving their DNS responses directly from the Pi-Hole? I ask because if you configured the Pi-Hole and tested using a client that was within the same VLAN as the Pi-hole, and then simply verified clients in a different VLAN were showing the same DNS server under their network config, it would be easy to assume they do. As you would not be able to tell the difference between a direct Pi-Hole response and one that was forwarded to and from the Pi-Hole via router interception ( forwarded to the Pi-Hole because that's the DNS server you set in the router under Basic->Network ) unless you specifically used a program ( such as nslookup ) on said client that shows you the IP for where the response came from. In addition, you would have had to specifically configure rules under Advanced->LAN Access to permit routed communication between clients in different VLANs. By default, the router will not forward packets, of any protocol or for any purpose, between clients in different VLANs. DNS or otherwise.
     
    Last edited: Mar 8, 2019
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice