Issue with dns with r7800 as access point

[MacJL]

Hello,

I’m using a R7800 as Access Point with latest Voxel Firmware.
I have an issue with DNS hijacking that randomly change DNS response to the IP of the R7800. I think it’s related to the ‘routerlongin.net’ stuff. But I don’t need this thing in AP Mode.
Is there a way to disable it?

This bug make the Router totally
unusable, redirecting all site to the IP address of the router.
I also have the same behavior on stock firmware.

 

[R. Gerrits]

Can you access the router/AP via ssh or telnet?

If so, can you check the nvram setting dns_hijack ?

nvram get dns_hijack

If that is set to 1, then dnsmasq (the dns server) on the router answers all DNS requests with its local IP address.

And also, this iptables rule in the PREROUTRING chain of the NAT table makes sure that even if you specify a different DNS server on your device, that it then still redirects the DNS request to the local router (which then again answers with its local address).
REDIRECT udp -- br0 * 0.0.0.0/0 !192.168.1.1 udp dpt:53 redir ports 53
(note, the Netgear/DNI people forgot that DNS traffic can also be tcp, if the request is bigger. So some DNS traffic to an external DNS server might make it through).

if dns_hijack is set back to 0, then that iptables rule changes to:
REDIRECT udp -- br0 * 0.0.0.0/0 !192.168.1.1 udp dpt:53UNKNOWN match `dnshijack' redir ports 53
i.e. it only redirects DNS traffic to the local DNS server for a handful of dns-names.
(www.routerlogin.com, www.routerlogin.net, routerlogin.com, routerlogin.net readyshare.routerlogin.net)

and to solve it:

nvram set dns_hijack=0
nvram commit

(NOTE, my reasoning is that the firmware should have set this to 0, once it finished the setup-wizard. So no guarantees that some process might set dns_hijack back to 1 again)

 

[MacJL]

Hello,

Thanks for pointing this parameter in nvram. I found many thing in iptables, but not in nvram! FYI, there are many rules that change the DNS routing. In iptables, ip6tables, ebtables, etc... but also in an other place I didn't found. Maybe in an iptables proprietary kernel module.

The nvram settings 'dns_hijack' was set to 0 when I looked at it.

But as I added a workaround (link), I don't know if I still have the issue yet. So I remove all I added in rc.local, and rebooted. I will see if the problem is still there, and if the nvram setting changes when the problem is present.

 

[MacJL]

Didn't had to wait long :

The nvram is set to 0 :

root@R7800:/$ nvram get dns_hijack
0

This is not the IP of Google :

% nslookup google.com
Server:        2a01:cb1d:90:800:a63e:51ff:fec6:b8f6
Address:    2a01:cb1d:90:800:a63e:51ff:fec6:b8f6#53

Name:    google.com
Address: 192.168.50.69

 

[R. Gerrits]

hmm strange... then apparently a R7800 in AP mode behaves differently with regards to dns_hijack then when in routermode.

Btw that workaround can be much easier -> just doing a net-wall stop should already flush all the iptables and ip6tables -> all those separate rules to flush the iptables are not needed.

Regarding flushing ebtables, did you ever see any rules in the ebtables that could explain the DNS issue? on my R7800 the ebtables contain no rules. (also they operate in L2, so i doubt they could be used to intercept DNS traffic)

Also there are processes that might restart the firewall -> in this case, because you removed the ipt-dnshijack, that reloading will fail half way through the process -> the end result is still that the redirect rule in the nat table is not present, but might introduce other strange behaviour.

And without the redirect rule, stopping the local dnsmasq should also not be needed (but on the other hand, it might not have much of a function on an AP).

The aclhijackdns, this is kind of a mystery to me. I cannot really determine what its purpose would be.


Anyways, if you use Voxel firmware, you could also replace your current workaround by adding this line to /opt/scripts/firewall-start.sh (create it and chmod +x if it doesn't exist):
iptables -t nat -D PREROUTING 1

this only removes the line responsible for the redirection, everytime the firewall is (re)started.

 

[MacJL]

hmm strange... then apparently a R7800 in AP mode behaves differently with regards to dns_hijack then when in routermode.

An other person have the same problem. It also seems to be related to the provider. In this case, Orange Livebox fibre with IPv6 enabled.

Btw that workaround can be much easier -> just doing a net-wall stop should already flush all the iptables and ip6tables -> all those separate rules to flush the iptables are not needed.

I've tested this at first, but it's not sufficient.

Regarding flushing ebtables, did you ever see any rules in the ebtables that could explain the DNS issue? on my R7800 the ebtables contain no rules. (also they operate in L2, so i doubt they could be used to intercept DNS traffic)

Yes, in the 'broute' table :

root@R7800:/$ ebtables -t broute -L
ebtables -t broute -L
Bridge table: broute

Bridge chain: BROUTING, entries: 2, policy: ACCEPT
-p IPv4 --ip-proto udp --ip-dport 53 --ip-dns-hijack -j redirect
-p IPv6 --ip6-proto udp --ip6-dport 53 --ip6-dns-hijack-j redirect

Also there are processes that might restart the firewall -> in this case, because you removed the ipt-dnshijack, that reloading will fail half way through the process -> the end result is still that the redirect rule in the nat table is not present, but might introduce other strange behaviour.

I suppose too. That's why I trying to find a better way to do it.

And without the redirect rule, stopping the local dnsmasq should also not be needed (but on the other hand, it might not have much of a function on an AP).

I tried without, but in that case, I still see some DNS request which reply the address of router. That's why I think there are other nf-tables rules I did not found. Maybe located in Netgear kernel modules.
The thing I didn't tried is to only stop dnsmasq to see if it's sufficient for a workaround.

The aclhijackdns, this is kind of a mystery to me. I cannot really determine what its purpose would be.

Anyways, if you use Voxel firmware, you could also replace your current workaround by adding this line to /opt/scripts/firewall-start.sh (create it and chmod +x if it doesn't exist):
iptables -t nat -D PREROUTING 1

this only removes the line responsible for the redirection, everytime the firewall is (re)started.

Thank you for your help, I'll try that (when family will not use internet, or I will be killed!)

 

[R. Gerrits]

btw, I was thinking: With an AP, traffic stays in the same subnet -> no routing happens, so removing that line from the prerouting chain in the nat table will most likely not change anything.

So probably in your case, only the two rules in ebtables are causing it.
if ebtables is also generated by net-wall, then you could try adding these in /opt/scripts/firewall-start.sh:
ebtables -t broute -D 2
ebtables -t broute -D 1

stopping dnsmasq will not work as a workaround. Because then ebtables would still redirect DNS traffic to the AP itself, but then nothing is there to respond.