OpenVPN and DNS flakey in 384.11.*

[Bubbagump210]

I am not even sure where to start to report an issue. So let me try to describe some behaviors. Firstly, 384.10_2 is solid for me and I have no issues. AC68U

• dnsmasq simply can't do a DNS lookup. If I leave the LAN DNS setting blank and only enter a WAN DNS entry so that the router acts as a middleman/cache, things don't work. However, maybe after a few hard boots suddenly DNS works for no apparent reason.
• OpenVPN will not connect to servers. Very similar to the point above, maybe after a few hard reboots and luck, it will come up and stay stable. Typically I see nothing more than "starting vpn_client1" in the logs vs what I typically see which is all of the cipher negotiation etc.

Any bright ideas? It feels like something is very wrong in 384.11+ (looks at all the newly linked libraries?)

 

[martinr]

The RT-AC68U is a good solid router, without the gremlins that can plague other models. That, together with no similar reports (that I know of) indicates the fault is at your end.

Which firmware version were you running before you upgraded to 394.11?

And how long ago since you carried out a reset to factory default settings (RFDS) using L&LD’s guide? Ideally, at which version did you last RFDS, but if you can’t remember that, I suppose a rough idea in months, years or decades would suffice.

 

[dosborne]

Had very similar issues (and posted about them). A reset and manual reconfig, as martinr suggests above, solved it for me.

https://www.snbforums.com/threads/ntp-issues-384-11-on-ac68u.56540/

 

[RMerlin]

LAN DNS has nothing to do with dnsmasq, they are only parameters that get forwarded to clients when they receive their DHCP lease. Your issue lies around the WAN DNS configuration.

 

[Bubbagump210]

Had very similar issues (and posted about them). A reset and manual reconfig, as martinr suggests above, solved it for me.

https://www.snbforums.com/threads/ntp-issues-384-11-on-ac68u.56540/

I'll give it a shot. That seems odd because as soon as I down grade to 384.10_2, everything works perfectly again. Thanks!

 

[Bubbagump210]

LAN DNS has nothing to do with dnsmasq, they are only parameters that get forwarded to clients when they receive their DHCP lease. Your issue lies around the WAN DNS configuration.

You lost me. The default behavior when you do not enter a LAN DNS server is for the router to issue its own internal IP as the DNS server for the LAN and it then resolves DNS via dnsmasq using upstream servers. So in my case, dnsmasq on the router is just sort of borked and doesn't resolve anything - even if I am sshd into the router and doing a lookup from router itself.

 

[dave14305]

So in my case, dnsmasq on the router is just sort of borked and doesn't resolve anything - even if I am sshd into the router and doing a lookup from router itself.

What’s in /etc/resolv.conf? That’s what nslookup on the router will use. If it’s 127.0.0.1, what’s in /tmp/resolv.dnsmasq?

 

[Bubbagump210]

What’s in /etc/resolv.conf? That’s what nslookup on the router will use. If it’s 127.0.0.1, what’s in /tmp/resolv.dnsmasq?

Aha! Now we're on to something.

admin@RT-AC68U-F698:/tmp/home/root# cat /etc/resolv.conf
nameserver 127.0.0.1

admin@RT-AC68U-F698:/tmp/home/root# cat /tmp/resolv.dnsmasq
server=10.8.0.1

10.8.0.1 is my Pihole on the other side of the VPN that isn't working. However, I have the WAN DNS set to 1.1.1.1 and 1.0.0.1.

So dnsmasq is not getting updated by the web GUI in this case. This doesn't speak to why OpenVPN doesn't work, but it is certainly a curiosity.

 

[dave14305]

Aha! Now we're on to something.

admin@RT-AC68U-F698:/tmp/home/root# cat /etc/resolv.conf
nameserver 127.0.0.1

admin@RT-AC68U-F698:/tmp/home/root# cat /tmp/resolv.dnsmasq
server=10.8.0.1

10.8.0.1 is my Pihole on the other side of the VPN that isn't working. However, I have the WAN DNS set to 1.1.1.1 and 1.0.0.1.

So dnsmasq is not getting updated by the web GUI in this case. This doesn't speak to why OpenVPN doesn't work, but it is certainly a curiosity.

Go to Tools / Other Settings and set "Wan: Use local caching DNS server as system resolver" to No. Then you'll be getting closer.

 

[Bubbagump210]

Go to Tools / Other Settings and set "Wan: Use local caching DNS server as system resolver" to No. Then you'll be getting closer.

That didn't change anything until I did a hard reboot and the settings changed to use /etc/resolv.conf directly. This feels like I need to nuke this thing back to the stone age as dosborne mentioned above. Thanks all.

 

[dave14305]

It's certainly the nuclear option, especially if you have no confidence in the current configuration and stability.

But if you can get good DNS resolution on the router, good DNS resolution from a client using the router IP as DNS, and good NTP sync on router boot, that's really half the battle.

 

[martinr]

...,This feels like I need to nuke this thing back to the stone age as dosborne mentioned above. Thanks all.

The nuclear codes can be found here. No shortcuts, mind you; stick to the nuclear protocol.

(Probably just triggered a weekend recall of all staff at the NSA and GCHQ)

 

[Bubbagump210]

I finally figured this out and it did not require nuking back to the stone age. The problem was that the router did not have good time. Here's the dependency tree of fuggery if anyone else runs into this.

WAN DNS: set to a Pihole which I access across a VPN (10.8.0.1)
LAN DNS: Set to nothing so that local clients use the dnsmasq instance on the router. I did this so that more is cached locally and doesn't have to query the Pihole. I know, the Pihole caches too, but why not cache more locally?
NTP: Set to pool.ntp.org

The router boots, it has no time, it tries to query NTP. At the same time, it is trying to reach DNS over a VPN tunnel that has not been established to resolve pool.ntp.org. The VPN never establishes as the system time is set to like 5 years ago (or whatever the default time is at boot) and thus the VPN negotiation fails.

So here I am in a catch 22... I can't get the VPN to start as I have bad time. I have bad time as the router can't find pool.ntp.org. I can't query pool.ntp.org as I can't get to my DNS as there is no VPN. Rinse, repeat.

The "fix" is to set the WAN DNS to 1.1.1.1 (or 8.8.8.8 or whatever) and let NTP pull good time. Once I pull good time, I then start the VPN. I then change the WAN DNS back to 10.8.0.1. It's a workaround as I'll have this issue after every reboot. I suppose I could just set NTP to a static IP of some NIST server and avoid this dork around... or alternatively forget about the VPN for DNS and put the Pihole locally.

 

[dave14305]

A popular solution to a similar problem in the early Stubby days was to add a directive to /jffs/configs/dnsmasq.conf.add

server=/pool.ntp.org/1.1.1.1

This directs queries for any name in pool.ntp.org to CloudFlare DNS (or your choice).

 

[Bubbagump210]

A popular solution to a similar problem in the early Stubby days was to add a directive to /jffs/configs/dnsmasq.conf.add

server=/pool.ntp.org/1.1.1.1

This directs queries for any name in pool.ntp.org to CloudFlare DNS (or your choice).

Very cool. Thanks for the tip!