Push DNS server from OpenVPN to client on connection

Technical Support for Routers
1

Hello.

I’ve got my ovpn server pushing its own local DNS to clients, but the ovpn client on my MT-300N-V2 is not accepting it. From the logs:

Tue Aug 14 13:13:56 2018 daemon.notice openvpn[6667]: PUSH: Received control message: ‘PUSH_REPLY,explicit-exit-notify,topology subnet,route-delay 5 30,dhcp-pre-release,dhcp-renew,dhcp-release,route-metric 101,ping 15,ping-restart 75,comp-lzo yes,redirect-gateway def1,redirect-gateway bypass-dhcp,redirect-gateway autolocal,route-gateway 10.27.0.145,dhcp-option DNS 172.31.0.2,register-dns,block-ipv6,ifconfig 10.27.0.151 255.255.255.240’
Tue Aug 14 13:13:56 2018 daemon.warn openvpn[6667]: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:4: dhcp-pre-release (2.4.3)
Tue Aug 14 13:13:56 2018 daemon.warn openvpn[6667]: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:5: dhcp-renew (2.4.3)
Tue Aug 14 13:13:56 2018 daemon.warn openvpn[6667]: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:6: dhcp-release (2.4.3)
Tue Aug 14 13:13:56 2018 daemon.warn openvpn[6667]: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:16: register-dns (2.4.3)
Tue Aug 14 13:13:56 2018 daemon.warn openvpn[6667]: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:17: block-ipv6 (2.4.3)

How can I get the client to use the DNS IP pushed by the server?

2
3

Thankyou, this worked like a charm!

4

ok, spoke too soon!

It does work as intended, however, whenever my modem renegotiates a new address from the carrier, it seems the DNS is reset to by the carrier’s own pushed address.

Aug 16 16:13:16 2018 daemon.info dnsmasq[2292]: using nameserver [DNS pushed from VPN]
Thu Aug 16 16:13:17 2018 user.notice firewall: Reloading firewall due to ifup of VPN_client (tun0)
Thu Aug 16 16:13:17 2018 daemon.info odhcpd[1328]: Using a RA lifetime of 0 seconds on br-lan
Thu Aug 16 16:13:21 2018 daemon.notice openvpn[3019]: /sbin/ip route add [VPN IP]/32 via 25.190.219.2
Thu Aug 16 16:13:21 2018 daemon.notice openvpn[3019]: /sbin/ip route add 0.0.0.0/1 via [VPN IP]
Thu Aug 16 16:13:21 2018 daemon.notice openvpn[3019]: /sbin/ip route add 128.0.0.0/1 via [VPN IP]
Thu Aug 16 16:13:21 2018 daemon.warn openvpn[3019]: WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
Thu Aug 16 16:13:21 2018 daemon.notice openvpn[3019]: Initialization Sequence Completed
Thu Aug 16 16:20:33 2018 daemon.info odhcpd[1328]: Using a RA lifetime of 0 seconds on br-lan
Thu Aug 16 16:30:21 2018 daemon.info odhcpd[1328]: Using a RA lifetime of 0 seconds on br-lan
Thu Aug 16 16:40:00 2018 daemon.info odhcpd[1328]: Using a RA lifetime of 0 seconds on br-lan
Thu Aug 16 16:48:21 2018 daemon.info odhcpd[1328]: Using a RA lifetime of 0 seconds on br-lan
Thu Aug 16 16:51:58 2018 daemon.info odhcpd[1328]: Using a RA lifetime of 0 seconds on br-lan
Thu Aug 16 16:55:42 2018 daemon.info odhcpd[1328]: Using a RA lifetime of 0 seconds on br-lan
Thu Aug 16 16:59:35 2018 daemon.info odhcpd[1328]: Using a RA lifetime of 0 seconds on br-lan
Thu Aug 16 17:07:57 2018 daemon.info odhcpd[1328]: Using a RA lifetime of 0 seconds on br-lan
Thu Aug 16 17:10:59 2018 daemon.notice netifd: modem_4 (2175): udhcpc: sending renew
Thu Aug 16 17:10:59 2018 daemon.notice netifd: modem_4 (2175): udhcpc: lease of [CARRIER-ISSUED IP] obtained, lease time 7200
Thu Aug 16 17:10:59 2018 daemon.info dnsmasq[2292]: reading /tmp/resolv.conf.auto
Thu Aug 16 17:10:59 2018 daemon.info dnsmasq[2292]: using local addresses only for domain [LAN DOMAIN]
Thu Aug 16 17:10:59 2018 daemon.info dnsmasq[2292]: using nameserver [CARRIER ISSUED DNS 1]#53
Thu Aug 16 17:10:59 2018 daemon.info dnsmasq[2292]: using nameserver [CARRIER ISSUED DNS 2]#53

Should I just add the same script to netifd? Any ideas on how to revert back to my VPN’s DNS server on carrier reneg?

5

Replacement of the up/down shell script to:

#!/bin/sh

case $script_type in
up)
	i=1
	ns=""
	while true; do
		# As we know, for non-Windows openvpn clients can accept push DHCP
		# options by using a client-side up script which parses the 
		# foreign_option_n environmental variable list
		eval opt=\$foreign_option_${i}
		[ -z "${opt}" ] && break

		ns="$ns\n$(echo ${opt} | sed -e 's/dhcp-option DOMAIN/domain/g' -e 's/dhcp-option DNS/nameserver/g')"

		i=$((i + 1))
	done

	if [ -n "$ns" ]; then
		echo -e "$ns" > /tmp/resolv.conf.vpn
	else
		echo -e "nameserver 209.244.0.3\nnameserver 64.6.64.6" > /tmp/resolv.conf.vpn
	fi

	uci set dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.vpn'
	uci commit dhcp
	# Let it runs on background, in order to avoid any delay to add route table,
	# which will effort to mwan3
	/etc/init.d/dnsmasq restart &
	;;
down)
	# Restore dns
	[ -f "/tmp/resolv.conf.vpn" ] || return 0
	rm -fr "/tmp/resolv.conf.vpn"
	uci set dhcp.@dnsmasq[0].resolvfile='/tmp/resolv.conf.auto'
	uci commit dhcp
	/etc/init.d/dnsmasq restart &
	;;
esac

exit 0
6

Thanks for this kyson-lok. It appears to work great on the “up” event.

However, the resolvfile doesn’t seem to get set back to /tmp/resolv.conf.auto on the “down” event. I’m not sure why.

The result is when I power up the device for the first time, the modem connects to the carrier, consumes the provided DNS, and uses it to resolve the VPN server. Once the connection is up, the script writes the VPN-pushed DNS IP to /tmp/resolv.conf.vpn and changes the resolvfile to this path. However, if the VPN connection closes (either intentionally or on carrier reneg), /tmp/resolv.conf.vpn gets cleared by the script but it is still showing as the path for the resolvfile. CORRECTION: the VPN-pushed IP is still in /tmp/resolv.conf.vpn after the vpn is down. So perhaps none of the down portion of the script is firing at all.

Any ideas why? Thought maybe I forgot to chmod the downdns shell script but that didn’t seem to be the case. Obviously, attempting to reconnect to the VPN a second time does not work since the server address does not resolve (because the resolvfile path is still pointing at /tmp/resolv.conf.vpn which contains the private VPN server-side DNS).

7

And one more observation. On reboot, the router is still trying to read /tmp/resolv.conf.vpn

Sat Aug 18 02:45:29 2018 daemon.warn dnsmasq[1922]: no servers found in /tmp/resolv.conf.vpn, will retry

I checked, and /tmp/resolv.conf.vpn is empty on reboot, so it never assigns a DNS, can’t resolve the VPN server domain, so its stuck without name resolution unless I manually update the resolvfile path to /tmp/resolv.conf.auto.

8

More interesting syslog errors…

On boot, OVPN connects normally…

Sat Aug 18 15:11:32 2018 daemon.warn openvpn[1502]: WARNING: --ns-cert-type is DEPRECATED. Use --remote-cert-tls instead.
Sat Aug 18 15:11:32 2018 daemon.warn openvpn[1502]: NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
Sat Aug 18 15:11:32 2018 daemon.notice openvpn[1502]: TCP/UDP: Preserving recently used remote address: [AF_INET]35.170.208.208:1194
Sat Aug 18 15:11:32 2018 daemon.notice openvpn[1502]: Socket Buffers: R=[163840->200000] S=[163840->200000]
Sat Aug 18 15:11:32 2018 daemon.notice openvpn[1502]: UDP link local: (not bound)
Sat Aug 18 15:11:32 2018 daemon.notice openvpn[1502]: UDP link remote: [AF_INET] {VPN Server IP removed}
Sat Aug 18 15:11:32 2018 daemon.notice openvpn[1502]: TLS: Initial packet from [AF_INET]{VPN Server IP removed}, sid=**{sid removed}
Sat Aug 18 15:11:32 2018 daemon.notice openvpn[1502]: VERIFY OK: depth=1, CN=OpenVPN CA
Sat Aug 18 15:11:32 2018 daemon.notice openvpn[1502]: VERIFY OK: nsCertType=SERVER
Sat Aug 18 15:11:32 2018 daemon.notice openvpn[1502]: VERIFY OK: depth=0, CN=OpenVPN Server

…until…

Sat Aug 18 15:11:34 2018 daemon.err openvpn[2814]: Halt command was pushed by server (‘disconnected due to new connection by same user’)

Not sure why a second session is being initiated…but the next one seems to complete normally.

Sat Aug 18 15:11:34 2018 daemon.notice openvpn[2814]: SIGTERM received, sending exit notification to peer
Sat Aug 18 15:11:34 2018 daemon.notice openvpn[1502]: Control Channel: TLSv1.2, cipher TLSv1/SSLv3 DHE-RSA-AES256-GCM-SHA384, 2048 bit RSA
Sat Aug 18 15:11:34 2018 daemon.notice openvpn[1502]: [OpenVPN Server] Peer Connection Initiated with [AF_INET]{VPN Server IP removed}
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: SENT CONTROL [OpenVPN Server]: ‘PUSH_REQUEST’ (status=1)
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[2814]: /sbin/ip route del {VPN Server IP removed}
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[2814]: /sbin/ip route del 0.0.0.0/1
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: PUSH: Received control message: ‘PUSH_REPLY,explicit-exit-notify,topology subnet,route-delay 5 30,dhcp-pre-release,dhcp-renew,dhcp-release,route-metric 101,ping 15,ping-restart 75,comp-lzo yes,redirect-gateway def1,redirect-gateway bypass-dhcp,redirect-gateway autolocal,route-gateway 10.27.0.145,dhcp-option DNS 172.31.0.2,register-dns,block-ipv6,ifconfig 10.27.0.154 255.255.255.240’
Sat Aug 18 15:11:35 2018 daemon.warn openvpn[1502]: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:4: dhcp-pre-release (2.4.3)
Sat Aug 18 15:11:35 2018 daemon.warn openvpn[1502]: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:5: dhcp-renew (2.4.3)
Sat Aug 18 15:11:35 2018 daemon.warn openvpn[1502]: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:6: dhcp-release (2.4.3)
Sat Aug 18 15:11:35 2018 daemon.warn openvpn[1502]: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:16: register-dns (2.4.3)
Sat Aug 18 15:11:35 2018 daemon.warn openvpn[1502]: Unrecognized option or missing or extra parameter(s) in [PUSH-OPTIONS]:17: block-ipv6 (2.4.3)
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: OPTIONS IMPORT: timers and/or timeouts modified
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: OPTIONS IMPORT: explicit notify parm(s) modified
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: OPTIONS IMPORT: compression parms modified
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: OPTIONS IMPORT: --ifconfig/up options modified
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: OPTIONS IMPORT: route options modified
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: OPTIONS IMPORT: route-related options modified
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: OPTIONS IMPORT: --ip-win32 and/or --dhcp-option options modified
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: Data Channel Encrypt: Cipher ‘AES-128-CBC’ initialized with 128 bit key
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: Data Channel Encrypt: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: Data Channel Decrypt: Cipher ‘AES-128-CBC’ initialized with 128 bit key
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: Data Channel Decrypt: Using 160 bit message hash ‘SHA1’ for HMAC authentication
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: TUN/TAP device tun1 opened
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: TUN/TAP TX queue length set to 100
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: /sbin/ip link set dev tun1 up mtu 1500
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[2814]: /sbin/ip route del 128.0.0.0/1

And then, seemingly out of nowhere…

Sat Aug 18 15:11:35 2018 daemon.notice openvpn[2814]: Closing TUN/TAP interface
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[2814]: /sbin/ip addr del dev tun0 10.27.0.155/28
Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: /sbin/ip addr add dev tun1 10.27.0.154/28 broadcast 10.27.0.159
> Sat Aug 18 15:11:35 2018 daemon.notice netifd: Network device ‘tun0’ link is down
> Sat Aug 18 15:11:35 2018 daemon.notice netifd: Interface ‘VPN_client’ has link connectivity loss
> Sat Aug 18 15:11:35 2018 daemon.notice netifd: Interface ‘VPN_client’ is now down
> Sat Aug 18 15:11:35 2018 daemon.notice openvpn[2814]: /etc/openvpn/downdns tun0 1500 1558 10.27.0.155 255.255.255.240 init
> Sat Aug 18 15:11:35 2018 daemon.notice openvpn[1502]: /etc/openvpn/updns tun1 1500 1558 10.27.0.154 255.255.255.240 init
> Sat Aug 18 15:11:35 2018 daemon.notice netifd: Interface ‘VPN_client’ is disabled
> Sat Aug 18 15:11:35 2018 daemon.err openvpn[2814]: WARNING: Failed running command (–up/–down): external program exited with error status: 2
> Sat Aug 18 15:11:35 2018 daemon.notice openvpn[2814]: Exiting due to fatal error
> Sat Aug 18 15:11:36 2018 daemon.info dnsmasq[3630]: exiting on receipt of SIGTERM
Sat Aug 18 15:11:36 2018 daemon.info odhcpd[1348]: Using a RA lifetime of 0 seconds on br-lan
Sat Aug 18 15:11:40 2018 daemon.info dnsmasq[4105]: started, version 2.78 cachesize 150
Sat Aug 18 15:11:40 2018 daemon.info dnsmasq[4105]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify
> Sat Aug 18 15:11:40 2018 daemon.warn dnsmasq[4105]: warning: ignoring resolv-file flag because no-resolv is set
Sat Aug 18 15:11:40 2018 daemon.info dnsmasq-dhcp[4105]: DHCP, IP range 10.29.14.100 – 10.29.14.249, lease time 12h

Here’s where it gets interesting… now that the VPN is disconnected, router is resorting back to manually entered explicit DNS IPs from the UI (Google)

Sat Aug 18 15:11:40 2018 daemon.info dnsmasq[4105]: using nameserver 8.8.4.4#53
Sat Aug 18 15:11:40 2018 daemon.info dnsmasq[4105]: using nameserver 8.8.8.8#53
Sat Aug 18 15:11:40 2018 daemon.info dnsmasq[4105]: using local addresses only for domain RVITclient.lan
Sat Aug 18 15:11:40 2018 daemon.info dnsmasq[4105]: read /etc/hosts - 4 addresses
Sat Aug 18 15:11:40 2018 daemon.info dnsmasq[4105]: read /tmp/hosts/dhcp.cfg02411c - 3 addresses
Sat Aug 18 15:11:40 2018 daemon.info dnsmasq[4105]: read /tmp/hosts/odhcpd - 1 addresses
Sat Aug 18 15:11:40 2018 daemon.info dnsmasq-dhcp[4105]: read /etc/ethers - 0 addresses
Sat Aug 18 15:11:40 2018 daemon.notice openvpn[1502]: /sbin/ip route add {VPN Server IP removed} via 22.80.170.1
Sat Aug 18 15:11:40 2018 daemon.notice openvpn[1502]: /sbin/ip route add 0.0.0.0/1 via 10.27.0.145
Sat Aug 18 15:11:40 2018 daemon.notice openvpn[1502]: /sbin/ip route add 128.0.0.0/1 via 10.27.0.145
Sat Aug 18 15:11:40 2018 daemon.warn openvpn[1502]: WARNING: this configuration may cache passwords in memory – use the auth-nocache option to prevent this
Sat Aug 18 15:11:40 2018 daemon.notice openvpn[1502]: Initialization Sequence Completed
Sat Aug 18 15:12:27 2018 daemon.info dnsmasq[4105]: read /etc/hosts - 4 addresses
Sat Aug 18 15:12:27 2018 daemon.info dnsmasq[4105]: read /tmp/hosts/dhcp.cfg02411c - 3 addresses
Sat Aug 18 15:12:27 2018 daemon.info dnsmasq[4105]: read /tmp/hosts/odhcpd - 1 addresses
Sat Aug 18 15:12:27 2018 daemon.info dnsmasq-dhcp[4105]: read /etc/ethers - 0 addresses

Once this is all said and done, the weirdest part is I can ping IP addresses and domain names from the router, but when I attempt to do either from a client, I get 100% packet loss. I’ll add that I checked the contents of all 3 resolvfiles and they are all holding the correct DNS addresses, but no traffic is getting through from clients, even without DNS.

When I run /etc/init.d/dnsmasq restart, I get:

udhcpc: started, v1.25.1
udhcpc: sending discover
udhcpc: no lease, failing

9

I consider that there has some errors on up/down script.

10

Seems like that is the issue, and perhaps only on the down portion of the script.

Also just noticed that there appears to be a little ‘war’ happening betweek the VPN-pushed DNS (Amazon) and the static DNS I entered in the UI (Google)

image
image1928×566 62.1 KB

And indeed, this appears to be evident in the syslog also:

Sat Aug 18 16:07:35 2018 daemon.notice netifd: Interface ‘VPN_client’ is enabled
Sat Aug 18 16:07:35 2018 daemon.notice netifd: Network device ‘tun0’ link is up
Sat Aug 18 16:07:35 2018 daemon.notice netifd: Interface ‘VPN_client’ has link connectivity
Sat Aug 18 16:07:35 2018 daemon.notice netifd: Interface ‘VPN_client’ is setting up now
Sat Aug 18 16:07:35 2018 daemon.notice netifd: Interface ‘VPN_client’ is now up
Sat Aug 18 16:07:35 2018 daemon.notice openvpn[3750]: TUN/TAP device tun0 opened
Sat Aug 18 16:07:35 2018 daemon.notice openvpn[3750]: TUN/TAP TX queue length set to 100
Sat Aug 18 16:07:35 2018 daemon.notice openvpn[3750]: do_ifconfig, tt->did_ifconfig_ipv6_setup=0
Sat Aug 18 16:07:35 2018 daemon.notice openvpn[3750]: /sbin/ip link set dev tun0 up mtu 1500
Sat Aug 18 16:07:35 2018 daemon.notice openvpn[3750]: /sbin/ip addr add dev tun0 10.27.0.152/28 broadcast 10.27.0.159
Sat Aug 18 16:07:35 2018 daemon.notice openvpn[3750]: /etc/openvpn/updns tun0 1500 1558 10.27.0.152 255.255.255.240 init
Sat Aug 18 16:07:35 2018 daemon.info dnsmasq[2034]: reading /tmp/resolv.conf.vpn
> Sat Aug 18 16:07:35 2018 daemon.info dnsmasq[2034]: using nameserver 8.8.4.4#53
> Sat Aug 18 16:07:35 2018 daemon.info dnsmasq[2034]: using nameserver 8.8.8.8#53
Sat Aug 18 16:07:35 2018 daemon.info dnsmasq[2034]: using local addresses only for domain RVITclient.lan
> Sat Aug 18 16:07:35 2018 daemon.info dnsmasq[2034]: using nameserver 172.31.0.2#53
Sat Aug 18 16:07:36 2018 daemon.info dnsmasq[2034]: exiting on receipt of SIGTERM
Sat Aug 18 16:07:36 2018 daemon.info odhcpd[1190]: Using a RA lifetime of 0 seconds on br-lan
Sat Aug 18 16:07:37 2018 user.notice firewall: Reloading firewall due to ifup of VPN_client (tun0)
Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: started, version 2.78 cachesize 150
Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: compile time options: IPv6 GNU-getopt no-DBus no-i18n no-IDN DHCP no-DHCPv6 no-Lua TFTP no-conntrack no-ipset no-auth no-DNSSEC no-ID loop-detect inotify
Sat Aug 18 16:07:39 2018 daemon.info dnsmasq-dhcp[4150]: DHCP, IP range 10.29.14.100 – 10.29.14.249, lease time 12h
> Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: using nameserver 8.8.4.4#53
> Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: using nameserver 8.8.8.8#53
Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: using local addresses only for domain RVITclient.lan
Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: reading /tmp/resolv.conf.vpn
> Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: using nameserver 8.8.4.4#53
> Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: using nameserver 8.8.8.8#53
Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: using local addresses only for domain RVITclient.lan
> Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: using nameserver 172.31.0.2#53
Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: read /etc/hosts - 4 addresses
Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: read /tmp/hosts/dhcp.cfg02411c - 3 addresses
Sat Aug 18 16:07:39 2018 daemon.info dnsmasq[4150]: read /tmp/hosts/odhcpd - 0 addresses
Sat Aug 18 16:07:39 2018 daemon.info dnsmasq-dhcp[4150]: read /etc/ethers - 0 addresses

11

You’re right, there is a conflict between custom dns and openvpn dns. If you wanna use openvpn dns, please remove custom dns on ui.

12

Ok, I’ve done that, but now I’m back to the problem that when the VPN disconnects, the down script isn’t replacing the OpenVPN DNS (private IP). This leaves the router attempting to connect to a DNS it can’t reach instead of resorting to a public or carrier-supplied DNS.