RT-AC87U Local DNS Problem

[cliver]

If you can SSH into your router and issue the following command we might be able to see the problem.

iptables-save -t nat

Output from iptable command below. Doesn't mean much to me I'm afraid.
Thanks for all the input everyone btw

# Generated by iptables-save v1.4.15 on Sun May  6 19:30:51 2018
*nat
:PREROUTING ACCEPT [800269:51213995]
:INPUT ACCEPT [33228391:2236946925]
:OUTPUT ACCEPT [97362:19939022]
:POSTROUTING ACCEPT [97362:19939022]
:DNSFILTER - [0:0]
:PUPNP - [0:0]
:VSERVER - [0:0]
:VUPNP - [0:0]
-A PREROUTING ! -d 10.101.202.0/24 -p tcp -m tcp --dport 80 -j DNAT --to-destina          tion 10.101.202.1:18017
-A PREROUTING -p udp -m udp --dport 53 -j DNAT --to-destination 10.101.202.1:180          18
COMMIT

 

[cliver]

maybe turn off "Connect to DNS Server automatically" (WAN DNS Setting), then enter your router's own IP address for DNS Server 1 (LAN - DHCP Server). i'm just guessing here.

Tried it but as expected, no difference

 

[Deleted member 51572]

Tried it but as expected, no difference

hmm, i'll take another stab in the dark: you say that clients are no longer reachable by name since WAN down', right? i'm wondering about UPnP, which does device discovery along with name resolution. is it enabled or disabled on the router? client devices supporting zeroconf should be able to discover each other on the network, even if UPnP is not enabled on the router, i think.

 

[cliver]

hmm, i'll take another stab in the dark: you say that clients are no longer reachable by name since WAN down', right? i'm wondering about UPnP, which does device discovery along with name resolution. is it enabled or disabled on the router? client devices supporting zeroconf should be able to discover each other on the network, even if UPnP is not enabled on the router, i think.

Yes UPnP is enabled as is UPnP secure mode.
Port ranges are at default values: Internal 1024 to 65535 External 1 to 65535.

I'm leaning toward the wanduck "Enable WAN down browser redirect notice" setting as the culprit but I can't find a way to stop it. Don't know enough about it to be honest so I'm loath to try stopping processes without knowing what I'm doing . Plus at the moment I am using my mobile as a hotspot for internet to get on here and check emails etc. and another to connect to the LAN for testing. Not an ideal scenario.
To be honest I have been merrily working on the assumtion that, if my WAN collapsed for any reason that my LAN would be fine. It's only now that it's actually happened that I find out that's not the case. I guess, with hindsight, that I should have tested it. I do find it rather odd that, on a consumer grade product, they don't default to a LAN that works without the WAN being present. I don't have anything over complex on my LAN, just a few computers serving things like music, video, TV streaming etc. and a NAS for all the files backed up to the cloud. Perhaps a bit more that most consumers would have but surely a simple enough LAN to expect it to work without the presence of a WAN connection.

 

[ColinTaylor]

@cliver As Dave previously said, wanduck is still redirecting your DNS requests. I don't know how to stop it doing that (and I can't experiment because I use a different firmware to you). My last thought would be to check Administration > System > Basic Config and make sure that Network Monitoring is disabled for both options (DNS and ping).

The UPnP options in the router have nothing to do with zeroconf discovery. The router's UPnP options are for IGD (firewall) and the media server. The router does have zeroconf support (there is no menu setting for it) running by default via the Avahi daemon. This would only really help supported clients find the router itself, not other clients. Unless all your clients are playing in Apple's walled garden this is unlikely to provide a satisfactory solution.

 

[cliver]

@cliver As Dave previously said, wanduck is still redirecting your DNS requests. I don't know how to stop it doing that (and I can't experiment because I use a different firmware to you). My last thought would be to check Administration > System > Basic Config and make sure that Network Monitoring is disabled for both options (DNS and ping).

The UPnP options in the router have nothing to do with zeroconf discovery. The router's UPnP options are for IGD (firewall) and the media server. The router does have zeroconf support (there is no menu setting for it) running by default via the Avahi daemon. This would only really help supported clients find the router itself, not other clients. Unless all your clients are playing in Apple's walled garden this is unlikely to provide a satisfactory solution.

Thanks Colin, Yes Network Monitoring is disabled/unchecked. Thanks for the idea though.

 

[ColinTaylor]

Maybe if you changed the "WAN Connection Type" from Automatic IP to Static (with some made up values) that might trick wanduck. You might have to turn the WAN connection back on, even though it doesn't do anything. Just a straw I thought I'd clutch.

EDIT: I suppose you could take a brute force approach and just run a script that deleted the two troublesome lines from the NAT table.

 

[cliver]

Maybe if you changed the "WAN Connection Type" from Automatic IP to Static (with some made up values) that might trick wanduck. You might have to turn the WAN connection back on, even though it doesn't do anything. Just a straw I thought I'd clutch.

EDIT: I suppose you could take a brute force approach and just run a script that deleted the two troublesome lines from the NAT table.

Changed WAN connection type but still no joy I'm afraid.
As for the script option. I'd like to find a setup that once in place wouldn't need any action to get the LAN up again when the WAN falls over, it just seamlessly carries on as if nothing had happened just with no WAN access.
I would need some hand holding to write and run the required script anyway. Out of interest though, which two lines are the problem ones?
Are you refering to the two starting "-A PREROUTING" ? If so what is wrong with them? They look ok to my untrained eye.

 

[ColinTaylor]

Yes it would be the PREROUTING ones. Thinking about it you'd only need to delete one of the lines. As a proof of concept try this:

1. Put your WAN connection type back the way it was (Automatic IP).
2. SSH into your router and issue the following command,

iptables -t nat -D PREROUTING -p udp -m udp --dport 53 -j DNAT --to-destination 10.101.202.1:18018

3. Test DNS again from a PC,

nslookup mydevice

 

[cliver]

Thanks Colin, I'll have a go at that later. I just want to update where I am on this.
I did prove that it was the redirect feature causing my issue by using a different browser (I use firefox normally) and when I try to browse anything on the WAN it redirects to a page on the router telling me the WAN is down, firefox was blocking the redirect.

So, I have now tethered my mobile to one of the usb ports on the router and set it up as a secondary WAN. and it works. My LAN is now responding correctly as is my WAN as a bonus, albeit rather slow.
So, my question now is: am I right in assuming that, if I set everything up as was, except for the WAN fail redirect option which I will turn off, in the future, if my WAN fails or I am between ISP's as I am now, that my LAN will/should keep working as normal?

 

[cliver]

OK, I have proved the answer to my question above. I have the wan redirection set to off and turned of the usb tethering on my mobile and my lan is now working as expected. So the redirect will not take effect if it is off and either main or secondary wan fails. Unfortunately, if you have it on and the wan fails there is no easy way to get it off. I will try Colins suggestion at some point to see if that would have worked but, using the if it ain't broke, don't fix it rule I'll get on with some catch up now I can access my LAN.
Thanks all for the input and ideas. I can do some work now