Router can not resolve DNS requests, but rest of network can

Hi everyone,

I am very happy with my current OpenWRT setup (Wireguard setup: Mullvad Client + Server for Android). Router is TP-Link TL-WDR3600 v1 running on OpenWRT 18.06.4.

Unfortunately I am running in a problem since yesterday. I did not change anything in my setup (well I thought so :face_with_raised_eyebrow:). My router seems to be unable to resolve any DNS requests, which are needed by OpenWRT itself. For example updating the system time or the dynamic IP. All DNS requests are send to a Pi-Hole in my network, which is supposed to take all requests, filter them, then send them to the Mullvad DNS server (193.138.218.74), a server which is reachable from in- and outside the Mullvad VPN tunnel (so it does not make a difference if I am connected to Mullvad or not).
The OpenWRT router is configured in a way, that all DHCP clients are using the Pi-Hole. For that I set under "DHCP and DNS" -> "DNS forwardings" to the static IP of my Pi-Hole (192.168.100.2) and in interface settings I disabled "Use DNS servers advertised by peer" for WAN and added Pi-Hole as first custom DNS and the Mullvad one as fallback.

I see ALL requests in the Pi-Hole log, and surfing works, also with blocking (checked by blacklisting facebook and try to call it). I also see the "dynupdate.no-ip.com" questioning in the Pi-Hole log. But the Pi-Hole seems not to answer. This is weird, but it is also weird, that obviously the fallback is also not working.

I tried setting "DHCP and DNS" -> "DNS forwardings" to 8.8.8.8 and the router seems to resolve the DNS questioning (at least it connected to Mullvad then, which was also not possible since mullvad was not resolved), but I do not really want to use another DNS server than the Pi-Hole.

Could someone please explain to me what I am doing wrong? And what is the difference between the two options for setting the DNS server? Thank you a lot!

Please find attached the syslog entries (I enabled "Write received DNS requests to syslog").

Best regards!

Mon Jan 13 19:10:25 2020 daemon.info dnsmasq[6208]: 18407 127.0.0.1/58847 query[A] dynupdate.no-ip.com from 127.0.0.1
Mon Jan 13 19:10:25 2020 daemon.info dnsmasq[6208]: 18407 127.0.0.1/58847 forwarded dynupdate.no-ip.com to 192.168.100.2
Mon Jan 13 19:10:25 2020 daemon.info dnsmasq[6208]: 18407 127.0.0.1/58847 forwarded dynupdate.no-ip.com to 192.168.100.2
Mon Jan 13 19:10:25 2020 daemon.info dnsmasq[6208]: 18407 127.0.0.1/58847 forwarded dynupdate.no-ip.com to 192.168.100.2
Mon Jan 13 19:10:25 2020 daemon.info dnsmasq[6208]: 18407 127.0.0.1/58847 forwarded dynupdate.no-ip.com to 192.168.100.2
Mon Jan 13 19:10:25 2020 daemon.info dnsmasq[6208]: 18407 127.0.0.1/58847 forwarded dynupdate.no-ip.com to 193.138.218.74
Mon Jan 13 19:10:25 2020 daemon.info dnsmasq[6208]: 18408 127.0.0.1/58847 query[AAAA] dynupdate.no-ip.com from 127.0.0.1
Mon Jan 13 19:10:25 2020 daemon.info dnsmasq[6208]: 18408 127.0.0.1/58847 forwarded dynupdate.no-ip.com to 192.168.100.2
Mon Jan 13 19:10:25 2020 user.err ddns-scripts[2778]: myddns_ipv4: cURL Error: '6'
Mon Jan 13 19:10:26 2020 user.warn ddns-scripts[2778]: myddns_ipv4: Transfer failed - retry 1425/0 in 60 seconds

Shouldn't you have the custom DNS on the LAN interface as well?

Clear the "DNS forwardings" field.

1 Like

Hi, thanks for helping! Unfortunately this did not work. I cleaned the field and restarted. Again, no mullvad connecting possible. Switched to 8.8.8.8, Mullvad is connected. Switching back to pihole, same as before... More ideas?

When you did so, did the clients have your DNS or not?

Did you try putting it for the LAN interface?

Yes, the Clients are always happy, it is only the router. Just checked the two lan interfaces, both also have the pi-hole as DNS. I just did not mentioned it. The router still allows me to surf but seems not to get answers from the pihole. Can this be something about security options, like a feature that forbids answers going back to the router?

Is the pi-hole responding with RFC1918 IPs? If so you might need to disable dnsmasq's rebind protection.

This also did not help. Same behaviour. But it seems to be something about the pihole. I tried to choose the Mullvad DNS directly at "DHCP and DNS" -> "DNS forwardings" and after rebooting the router managed to connect to mullvad and update the dyn IP. Nevertheless now I do not know which DNS is used for what. Looking to syslog sometimes Pihole is used (also for requests from the router), sometimes directly Mullvad DNS. I do not get what is happening here. I just want control over my DNS! :smile:

Could someone explain, what the difference of all the ways to set the DNS in OpenWRT is?
I can set it in:

  • DHCP and DNS
  • for interface WAN
  • for interface LAN

Is there an option that allows to specify one only used by the router? This would be a compromise, if I can be sure, that all clients only use the Pi-Hole, and the router still works.

If you assign IP via DHCP Option No. 6, you can have all the clients use the PiHole.

Or in /etc/config/dhcp

config dhcp 'lan'                                
        option interface 'lan' 
        option start '100'                 
        option limit '150'                       
        option leasetime '12h'             
        option dhcpv6 'server'                   
        option ra 'server'     
        option ra_management '1'
        list dhcp_option '6,192.168.1.xxx'
1 Like

Thank you, tried it out! It looks good, but I still see log entries that show me, that the pihole is not exclusive: Mullvad DNS ist asked from the router not from the pihole and even before the pihole was asked.

Tue Jan 14 20:23:57 2020 daemon.info dnsmasq[2275]: 2776 10.14.0.3/8385 forwarded mail.tutanota.com to 193.138.218.74
Tue Jan 14 20:23:57 2020 daemon.info dnsmasq[2275]: 2776 10.14.0.3/8385 forwarded mail.tutanota.com to 192.168.100.2
Tue Jan 14 20:23:57 2020 daemon.info dnsmasq[2275]: 2776 10.14.0.3/8385 forwarded mail.tutanota.com to 192.168.100.2
Tue Jan 14 20:23:57 2020 daemon.info dnsmasq[2275]: 2776 10.14.0.3/8385 forwarded mail.tutanota.com to 192.168.100.2
Tue Jan 14 20:23:57 2020 daemon.info dnsmasq[2275]: 2776 10.14.0.3/8385 forwarded mail.tutanota.com to 193.138.218.74
Tue Jan 14 20:23:57 2020 daemon.info dnsmasq[2275]: 2776 10.14.0.3/8385 reply mail.tutanota.com is 81.3.6.164

Okay, I checked again with blocking facebook and the Pi-Hole is NOT used.

Basically I still do not get, which of the options I really need. In the theory it is simple: every DNS request shall be send to the Pi-Hole, all clients shall use the Pi-Hole. The Pi-Hole shall use Mullvad DNS. The Pi-Hole is reachable from all VLANs. Let's say we start from scratch and I remove all DNS changes in OpenWRT. Which option do I need now?

  • The forwarding in "DHCP and DNS"?
  • DHCP option No. 6?
  • The option in WAN/WAN6?
  • The option in LAN/LAN2?

I guess by mixing all of them up I build a crazy forwarding-loop between router, pi-hole and mullvad or something similar.

The one single change you need is disabling peerdns on your WAN interface and adding the PiHole as DNS server.

If the PiHole replies with private IP addresses to DNS queries (I do not know how it works) then you need to disable dnsmasq's rebind protection as well.

1 Like

Hi,

okay I tried it. Back to scratch: I removed the forwarding in DHCP and DNS, in lan, in lan2 and in the DHCP options for lan and lan2. Only DNS is the pihole in wan options, and removed peerdns. I also removed the Mullvad DNS Fallback in wan DNS. wan6 has no DNS at all. Reboot. Result: router can not connect to Mullvad. Disabling rebind protection, reboot. Same. So nothing new here.

But I found out some things nevertheless. I can bring the router (and Mullvad VPN interface) to live, when I CHANGE the forward DNS option in "DHCP and DNS" after booting. It does not matter then if I choose the Mullvad one or 8.8.8.8 (BUT NOT PIHOLE), it will resolve the mullvad wireguard server instantly. After the connection to mullvad I can remove the forward DNS option and use the router normally, and all clients seem to use the pihole as well (facebook still blocked, rest working).

This brings me to a point where I think about the question what happens when booting. Is it possible that some interfaces can not use the pihole what I did not experienced when the router was already connected (only checking the clients)?

And could it furthermore be, that CHANGING the forward DNS server justs restarts some services, while the order of starting is resulting in different DNS server usage?

I am really confused here...

Maybe for information: the pihole is in lan1, all members which use mullvad are in lan2. Nevertheless these members seem to work fine with pihole.... More ideas?!

UPDATE: when I choose 8.8.8.8 for DNS forwarding and reboot it also works. What is the difference between Mullvad DNS there and Google? But even if I would accept that I need something chosen in there I can not accept that also clients then start to use 8.8.8.8... It is really frustrating.

UPDATE2: I loaded the complete OpenWRT working config from September. Same behaviour. I get the feeling the pi-hole is broken/missbehaving. I tried nslookup on the router, but he can't resolve anything. Also interesting: when calling my nextcloud over its dyndns name in my network I get "Rejected request from RFC1918 IP to public server address". This was never a thing since I added an entry in /etc/config/dhcp which is still there. Trying to disable rebind protection again did not the trick also.

I asked in the Pihole forum. They think it is a question of port forwarding / firewall. Ideas for that? Here is my network config:
192.168.100.1: router
192.168.100.2: pihole
192.168.100.4: nextcloud

For summarize: the router can not resolve domains with any mentioned settings. The pihole itself works for the clients. The router has problems with resolving at all since even his own dhcp.conf entries (nextcloud) seems to be broken. Also internal packet manager can not connect. Only thing known working: using google dns (8.8.8.8) in "DHCP and DNS" as Forwarding option.
Rebind protection has NO influence.


config interface 'loopback'
        option ifname 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'

config interface 'lan'
        option type 'bridge'
        option proto 'static'
        option netmask '255.255.255.0'
        option ip6assign '60'
        option ipaddr '192.168.100.1'
        option ifname 'eth0.1'

config interface 'wan'
        option ifname 'eth0.2'
        option proto 'dhcp'
        option peerdns '0'
        option dns '193.138.218.74'

config interface 'wan6'
        option ifname 'eth0.2'
        option proto 'dhcpv6'
        option reqaddress 'try'
        option reqprefix 'auto'
        option peerdns '0'

config switch
        option name 'switch0'
        option reset '1'
        option enable_vlan '1'

config switch_vlan
        option device 'switch0'
        option vlan '1'
        option vid '1'
        option ports '0t 2 3 4'

config switch_vlan
        option device 'switch0'
        option vlan '2'
        option ports '0t 1'
        option vid '2'

config interface 'wg0'
        option proto 'wireguard'
        option private_key '...'
        option listen_port '1234'
        list addresses '10.14.0.0/16'

config wireguard_wg0
        option public_key '...='
        list allowed_ips '10.14.0.3/32'
        option route_allowed_ips '1'
        option persistent_keepalive '25'

config wireguard_WGMV
        option public_key '...='
        list allowed_ips '0.0.0.0/0'
        option route_allowed_ips '1'
        option endpoint_host 'de2-wireguard.mullvad.net'
        option endpoint_port '51820'
        option persistent_keepalive '25'

config wireguard_wg0
        option public_key '...'
        list allowed_ips '10.14.0.4/32'
        option route_allowed_ips '1'
        option persistent_keepalive '25'

config interface 'wg_mv'
        option proto 'wireguard'
        option private_key '...='
        option listen_port '51820'
        list addresses '10.64.48.224'
        option force_link '1'

config wireguard_wg_mv
        option public_key '...'
        list allowed_ips '0.0.0.0/0'
        option endpoint_host 'de1-wireguard.mullvad.net'
        option endpoint_port '51820'
        option persistent_keepalive '25'

config switch_vlan
        option device 'switch0'
        option vlan '3'
        option vid '3'
        option ports '0t 5'

config interface 'lan2'
        option type 'bridge'
        option proto 'static'
        option ipaddr '192.168.200.1'
        option netmask '255.255.255.0'
        option ifname 'eth0.3'
        option dns '192.168.100.2'

config rule
        option in 'lan2'
        option dest '0.0.0.0/0'
        option priority '6'
        option lookup '2'

config rule
        option in 'wg0'
        option dest '0.0.0.0/0'
        option priority '7'
        option lookup '2'

config route
        option interface 'wg_mv'
        option target '0.0.0.0'
        option netmask '0.0.0.0'
        option table '2'

config rule
        option in 'lan2'
        option dest '192.168.100.4/32'
        option priority '2'
        option lookup 'main'

config rule
        option in 'wg0'
        option dest '192.168.100.4/32'
        option priority '3'
        option lookup 'main'

config rule
        option in 'lan2'
        option dest '192.168.100.2/32'
        option priority '4'
        option lookup 'main'

config rule
        option in 'wg0'
        option dest '192.168.100.2/32'
        option priority '5'
        option lookup 'main'


This sounds quite similar.

I did not really understood the problem, but it really seems to be a question of wrongly combining DNS options in OpenWRT as mentioned in the previous post.

I now have reset everything (also using ISP default DNS in WAN interfaces) and only have told all lan clients via DHCP option 6 to use the pihole. This works. The Wireguard clients are using directly the pihole via DNS option in the Android Wireguard app. This made it working for me. I can live with the fact, that inital Mullvad connection, time synch and updates do not run via the pihole since these are connections directly from the router. But maybe I can fix this too in the future. Thanks for helping nevertheless!