Diversion Diversion problems with dnsmasq through VPN interface

[georgev]

I just upgraded my Diversion version from 4.1.3 to 4.3.3 (I know, quit a leap). Doing so has broken a key part of my network setup: my dnsmasq queries need to be resolved through my vpn interface "tun12" to avoid DNS leaks on my VPN'd network. I can accomplish this via the following lines for NordVPN DNS servers in my dnsmasq.conf:

server=103.86.96.100@tun12
server=103.86.99.100@tun12

I was operating this way with no problem. However, since the upgrade, it ignores the @tun12 in my dnsmasq config, and I have a DNS leak.

I can do "/opt/etc/init.d/S56dnsmasq restart" which fixes my leak by applying my /opt/etc/dnsmasq.conf file which is set correctly, however doing so causes many DHCP issues where my statically assigned devices can no longer get IP addresses. Once I restart diversion or I do "service restart_dnsmasq", it fixes my DHCP issues, but re-introduces the DNS leak.

Any insights on how I should go about fixing this? I've found that hardcoding the correct server addresses with interfaces in my /tmp/resolv.dnsmasq file then "service restart_dnsmasq" does resolve the issue, but that seems like a hacky work around. Is there some problem with diversion that it digests the dnsmasq.conf file in an incomplete way (ignoring interfaces) then modifies conf files incorrectly when it starts? Frankly, I'm pretty unclear on a) what happens when I do service restart_dnsmasq, and b) what tweaking diversion does to my dnsmasq configuration. Any info on that would be much appreciated!

 

[thelonelycoder]

Any insights on how I should go about fixing this? I've found that hardcoding the correct server addresses with interfaces in my /tmp/resolv.dnsmasq file then "service restart_dnsmasq" does resolve the issue, but that seems like a hacky work around.

Kudos for your hack of applying settings to Dnsmasq!
But things were made much simpler if you look at the Asuswrt-Merlin Wiki on GitHub.

/tmp/resolv.dnsmasq is a temp file that gets recreated dynamically every time Dnsmasq ist started or restarted.
As per the Wiki, simply create the file /jffs/configs/dnsmasq.conf.add and insert

server=103.86.96.100@tun12
server=103.86.99.100@tun12

into it. Then restart Dnsmasq with service restart_dnsmasq.
Make sure to remove the file /opt/etc/init.d/S56dnsmasq before that as it is useless in your case. Things in this file do not get applied to the routers Dnsmasq when it is restarted.

Your hack disappeared during the Diversion update because Diversion restarted Dnsmasq during the update.
Doing it the proper way for Asuswrt-Merlin will fix your problem.

 

[georgev]

Thanks for the speedy response! Unfortunately I still am not having luck with the /jffs/configs/dnsmasq.conf.add file. Here was my procedure:

rm /opt/etc/init.d/S56dnsmasq
touch /jffs/configs/dnsmasq.conf.add
chmod +x /jffs/configs/dnsmasq.conf.add

# I edited /jffs/configs/dnsmasq.conf.add to add the following lines:
#   server=103.86.96.100@tun12
#   server=103.86.96.100@tun12

service restart_dnsmasq

I looked at /tmp/resolv.dnsmasq and it didn't appear to be modified when I did service restart_dnsmasq. Then I restarted my router and saw the problematic /tmp/resolv.dnsmasq file I've been seeing:

# /tmp/resolv.dnsmasq
server=103.86.96.100
server=103.86.99.100
server=103.86.96.100
server=103.86.96.100
server=103.86.99.100

Note that I only expect the two entries, but ever since I update diversion I now see many duplicates.

So as I noticed before I created the dnsmasq.conf.add file, service restart_dnsmasq does not seem to touch /tmp/resolv.dnsmasq.

Also, as an FYI, I wasn't modifying /tmp/resolv.dnsmasq prior to my upgrade of diversion. Previously, everything seemed to honor my /opt/etc/dnsmasq.conf file, so my dns queries were going through my VPN just fine, even through many power cycles of the router.

 

[georgev]

Further troubleshooting: It looks like the /tmp/resolv.dnsmasq file gets messed up (set to the non-tunnel interface) when I restart my vpn, which also (I think) causes dnsmasq to reconfigure. Not knowing all of what is happening during the startups of these processes, I'm a little handicapped at figuring this out. Here is a timeline of scripts that get called when I "reset my vpn" by calling /jffs/scripts/openvpnclient2.postconf:

1. /jffs/scripts/openvpnclient2.postconf does the following: killall openvpn, use API calls to get a sorted list of top VPN candidates, launch openvpn with a config based on the top candidate
2. /jffs/scripts/dnsmasq.postconf gets called somehow (autogenerated by diversion?) to call /opt/share/diversion/file/post-conf.div

I've tried forcing my /tmp/resolv.dnsmasq to the correct contents with an 'echo "..." > /tmp/resolv.dnsmasq' line in the following places:

1. At the beginning of openvpnclient2.postconf (doesn't fix the /tmp/resolv.dnsmasq)
2. At the end of openvpnclient2.postconf (doesn't fix /tmp/resolv.dnsmasq)
3. At the beginning of dnsmasq.postconf before /opt/share/diversion/file/post-conf.div (does fix /tmp/resolv.dnsmasq)

So it looks like somewhere after openvpn starts up and before dnsmasq.postconf gets called is when /tmp/resolv.dnsmasq gets overwritten with junk. Any thoughts?

 

[thelonelycoder]

Sorry I read things wrong and misguided you. /jffs/configs/dnsmasq.conf.add adds to /tmp/etc/dnsmasq.conf
/jffs/configs/dnsmasq.conf.add will not add to /tmp/resolv.dnsmasq.

I believed you were talking about dnsmasq.conf as you wrote

I can accomplish this via the following lines for NordVPN DNS servers in my dnsmasq.conf:

Back to the roots then. How did you add the server entries again?

 

[georgev]

Correct, I have two lines in my /opt/etc/dnsmasq.conf file:

server=103.86.96.100@tun12
server=103.86.99.100@tun12

That was the only place I pointed to those servers with that interface in my previous working setup. That seemed to set up /tmp/resolv.dnsmasq just fine before, but now something is clobbering that

 

[thelonelycoder]

I don‘t see how that file can modify resolv.dnsmasq as it is in the Entware file structure.
You must have somehow replaced the content in resolv.dnsmasq by another bit of code somewhere else.
Can you post the content of /opt/etc/init.d/S56dnsmasq

 

[georgev]

Keep in mind I've moved S56dnsmasq elsewhere so it shouldn't be called anymore (I've tucked it away in /opt/home).

#!/bin/sh

ENABLED=yes
PROCS=dnsmasq
ARGS=""
PREARGS=""
DESC=$PROCS
PATH=/opt/sbin:/opt/bin:/opt/usr/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

. /opt/etc/init.d/rc.func

 

[thelonelycoder]

You may run a separate Dnsmasq instance on Entware. That is unusual as the router already runs it’s own version.
Please post output of these commands:

which dnsmasq
dnsmasq -v
/opt/sbin/dnsmasq -v

 

[thelonelycoder]

Also, what's the full content of /tmp/resolv.dnsmasq

 

[georgev]

Unfortunately it's just the one dnsmasq. Version 2.88.

which dnsmasq output:
/opt/sbin/dnsmasq

dnsmasq -v output:
Dnsmasq version 2.88 Copyright (c) 2000-2022 Simon Kelley
Compile time options: IPv6 GNU-getopt no-RTC no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset no-nftset auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile

This software comes with ABSOLUTELY NO WARRANTY.
Dnsmasq is free software, and you are welcome to redistribute it
under the terms of the GNU General Public License, version 2 or 3.

/opt/sbin/dnsmasq -v output:
Dnsmasq version 2.88 Copyright (c) 2000-2022 Simon Kelley
Compile time options: IPv6 GNU-getopt no-RTC no-DBus no-UBus no-i18n no-IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset no-nftset auth no-cryptohash no-DNSSEC no-ID loop-detect inotify dumpfile

This software comes with ABSOLUTELY NO WARRANTY.
Dnsmasq is free software, and you are welcome to redistribute it
under the terms of the GNU General Public License, version 2 or 3.

 

[thelonelycoder]

My assumption is that the Entware Dnsmasq was installed to solve the DNS leak and you followed some advice given somewhere.
Given that, I believe you can safely remove the Entware Dnsmasq installation.

But before you do that, let's test if my theory is correct. This may not be the best way to accomplish this but if it works it will work seamless with Diversion.

1. Stop Entware Dnsmasq: /opt/etc/init.d/S56dnsmasq stop
2. Disable Entware Dnsmasq: Set ENABLED=yes to ENABLED=no in /opt/etc/init.d/S56dnsmasq
3. Remove file /jffs/configs/dnsmasq.conf.add
4. Create /jffs/resolv.dnsmasq and populate it with

server=103.86.96.100@tun12
server=103.86.99.100@tun12

5. Modify /jffs/scripts/dnsmasq.postconf by adding the pc_replace line after the Diversion file, like so:

#!/bin/sh
. /opt/share/diversion/file/post-conf.div # Added by Diversion
pc_replace 'servers-file=/tmp/resolv.dnsmasq' 'servers-file=/jffs/resolv.dnsmasq' $CONFIG

As a side note, the variable $CONFIG is defined in my Diversion file.
6. Restart the routers Dnsmasq with service restart_dnsmasq

See if that works for you. If it does, go ahead and reboot the router to test that it still works after.

 

[georgev]

Works like a charm! Since we've started this thread, my interim solution has been to hide S56dnsmasq and to add the line:

echo -e 'server=103.86.96.100@tun12\nserver=103.86.99.100@tun12' > /tmp/resolv.dnsmasq

at the end of my /jffs/scrips/dnsmasq.postconf. However, your solution also works and is more elegant. Thanks so much for your help!