Resolv.conf.auto changing to 192.168.1.1?


#1

What process changes /tmp/resolv.conf.auto ?

It is setting the file to:

# Interface wwan
nameserver 192.168.1.1

DNS resolution on the local router fails when it gets set to this. Clients all work fine. I change the file to:

nameserver 192.168.8.1

… and resolution works properly again from the router. But something changes it back every so often. I haven’t been able to pinpoint what it is yet…

I’m running 3.10 on the AR300m


Trouble resolving DNS for my OpenVPN connections
#2

Well come to find it is set by udhcpc to go to the upstream dns server. When VPN is active this is blocked by the firewall… so DNS resolution doesn’t work. opkg update fails, etc…

I thought this was set to 192.168.8.1 before? Or maybe I just screwed something up somewhere?

Can anyone else verify?


#3

can you set up custom dns and try?


#4

Yes, I have it set to 1.1.1.1 . All clients connected to the router use this. But on command prompt of the router it uses 192.168.1.1 as set by the upstream DNS in /etc/resolv.conf

If I go into Luci I can set the WWAN interface DNS to be 192.168.8.1 and it will update /etc/resolv.conf. But I’m not sure if this will break the captive portal I’m behind now.


#5

This is actually a problem.

Wether the router should use vpn (as well as its DNS) to communicate or not? Some people want the router will use vpn as well. This will break ddns

Some people only want the client use vpn.


#6

The VPN leak protection stops the router from using the upstream DNS - package installs, firmware upgrades and checks also break.

I would think that if no DNS is manually configured the upstream DNS should be allowed to pass the leak protection. But this is a bad configuration. A warning should be displayed to manually configure one or maybe provide the option to use predefined Cloudflare, OpenDNS, or Google settings. And these IP’s should be allowed through the leak protection.


#7

I agree, this is a problem, but also complicated when you factor in things like captive portal resolution. In my case it was preventing my VPN connection because the upstream router’s DNS did not resolve the VPN address. A custom DNS was configured in the settings, but that only helped the clients not the router itself.

Maybe there needs to be a “switch” in the GUI for this? Something that allows switching the router’s DNS between the upstream DHCP DNS and the custom configured DNS. I think that would solve my problem, but these issues are complex so it’s hard to see whether that solves the problem for everyone or not. I appreciate that you are trying to find a balance between good functionality and an easy configuration experience.


#8

It seems that it is a problem. I had added it to bug tracker.