Posted: Mon Oct 15, 2018 22:25 Post subject: Query on OpenVPN DNS using advanced PBR script
Hi, I have a query about how to check how OpenVPN DNS queries are being routed. I'm using eibgrad's PBR script: https://pastebin.com/nC27ETsp
I have a Netgear R7800 using Firmware: DD-WRT v3.0-r37120M kongat (10/03/18) and I'm using DNSMasq for DHCP and DNS
TL;DR - when using the OpenVPN client how can I check if DNS queries are being routed over the VPN or the WAN?
Long version:
I have configured both the OpenVPN client and an OpenVPN server on the same router.
I spent a lot of the weekend reading posts by eibgrad, egc and others, and more or less worked out how to achieve what I wanted. However I couldn't get the client and the server to work simultaneously. If the VPN client was connected, an external device connecting to the VPN server couldn't see any LAN devices.
I wanted to use PBR, and that got me to the point I could connect external devices to any LAN client except ones in the GUI PBR list. So I started playing around with eibgrad's excellent PBR script. With this I could now simultaneously connect outbound and inbound, and everything could see everything else.
So far, so good. (I've included the above background in case anything is relevant to my query.)
However... although the VPN provider (NordVPN) pushes "dhcp-option DNS x.x.x.x" commands in their config, every DNS leak test I can try on PBR clients shows they are still using the WAN DNS servers, not the VPN ones.
I was originally going to ask if anyone can help me work out why the router OpenVPN client is ignoring the DNS servers pushed by the VPN provider.
However the VPN DNS servers don't seem fast, so I could keep using my normal WAN DNS - if I could see that DNS queries from PBR clients are definitely going via the VPN, not just straight out on the WAN. (I should probably just trust the script, but I like to see things and understand them.)
but there's no /proc/net/ip_conntrack file, there is one called /proc/net/nf_conntrack, is this the same thing? I've run the command against that file and it shows useful output, but I lack the expertise to tell which way these queries are being routed.
Can anyone advise me how to tell whether my DNS queries are being routed over the VPN, or just straight out of the WAN? What should I be looking for in the watch command output?
Thanks, but unless I've completely misunderstood, that tells me which DNS servers I'm using. As far as I can see it doesn't tell me how I'm routing to them, i.e. over the WAN or over the VPN tunnel. Or am I missing something?
I know that the VPN DNS servers aren't being used by the client on the router. But I believe that even if using my normal DNS servers, the script should route DNS queries down the tunnel...?
Edit:
There is also a DNS leak, your ISP's DNS server is always added to the queried DNS servers.
see: https://svn.dd-wrt.com/ticket/6020 and https://svn.dd-wrt.com/ticket/6320
To be sure that only the DNS servers are used which you specifiy, add the following to Additional DNSMAsq Options:
As I mentioned /proc/net/ip_conntrack doesn't exist, but nf_conntrack does, I ran the watch command against that instead - does it serve the same purpose?
https://svn.dd-wrt.com/ticket/6320 also explains to me why the VPN-pushed "dhcp-option DNS" commands are being ignored. Or at least confirms it's a bug.
Quote:
To be sure that only the DNS servers are used which you specifiy, add the following to Additional DNSMAsq Options:
Thanks, already done following advice from these forums.
The only relevant entries in nf_conntrack that I can see are:
Which I'm taking as meaning that the DNS request is going over the WAN IP and not the VPN IP.
Am I interpreting it correctly? Am I missing some firewall rules to facilitate this - I haven't added any but have let the GUI handle everything.
Update: I may be a bit closer to working it out. With route-noexec in the Additional Config of the VPN client, all DNS traffic from all clients appears to be routed over the WAN. Without it, all traffic, DNS or otherwise, seems to be routed over the VPN, even for clients that aren't in the PBR script. Actually, no, I'm not sure if that tells me anything useful. Or if it does it's beyond me.
I must have something configured incorrectly but can't work out what. I might tear it all down and start again from scratch just to check I haven't entered anything incorrectly. Do I need to add any iptables rules in the firewall or should those all be handled automatically based on GUI settings?
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Wed Oct 17, 2018 9:17 Post subject:
That is odd I just checked and I have both ip_conntrack and nf_conntrack (which shows more or less the same)
I am using Kong's 37015 but on Broadcom so Linux K4.4
You are still on 3.18 (there is a 4.9 test build from yesterday I saw) that is probably the cause.
But back to the problem when anything routed over the WAN it should be like
my client 192.168.1.89 queries my router at 192.68.1.1
my router WAN at 192.168.0.2 then queries the DNS server at 209.222.18.22
(Note this is a test bed so my WAN is internal)
my client 192.168.1.89 queries my router at 192.68.1.1
my VPN at 10.76.10.6 then queries the DNS server at 209.222.18.22
So that works as expected but I am not using the script.
Regarding route-noexec, this is what gets you off the default VPN and on the WAN.
Route-noexec is inserted by DDWRT when something is in the PBR field
When using the script a route to the DNS server via the VPN is added I think so you should see them by doing "ip route" and "ip route show table 200"
The one thing I am not sure of, is where the scripts gets the DNS servers from, it could be the ones pushed by the VPN provider and if you use the "no-resolv" in DNSMAsq that could be causing trouble
Thanks, there's a lot to think about there and it's late here, so just a few quick(ish) replies.
I am on the 4.19 test release, it was the 3rd Oct one but I've also just tried the new one. I will try other builds though and hopefully try another router at the weekend just in case there's something odd with the R7800 build. And a clean start would probably be a good idea as well, starting with the built-in PBR stuff first.
The example of a working output from the watch command helped a lot, thanks.
Running the ip route commands shows there is a route to the VPN's DNS, so that seems to have been added okay. I'm still not sure whether I should be expecting it to actually use the VPN DNS servers though, or just route queries to my normal DNS over the tunnel due to the bug.
Commenting out the no-resolv in dnsmasq options, I still ended up using the ISP DNS, still not the VPN ones, and over the WAN not the VPN. It was a quick check though so I'll try again another time in case I missed something.
Appreciate the help and detailed replies. I'll do some testing and report back in case anyone has more ideas. I'm not sure of the etiquette on these forums, I've lurked on and off for a while but don't really know if it's okay to PM eibgrad about this thread or if I just hope he might notice it and have time to reply...
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Thu Oct 18, 2018 9:32 Post subject:
I would think that you only PM @Eibgrad in case of emergency, this might not qualify.
However in this case I think you can try it, he is always very helpfull, just ask his attention to this thread
I took a closer look at the script and here is my breakdown ( for what it is worth):
If you use the script, by default everything is routed through the tunnel, only the IP addresses of clients specified are routed through the WAN.
This is in reverse how PBR normally works.
So by default also all DNS queries are routed through the tunnel.
The behavior reverses is you specify "route-noexec' in the VPN additional config.
By default everything is then routed through the WAN, IP addresses of clients specified are routed through the tunnel.
This is where the DNS is routed through the WAN.
But if you enable the "ROUTE_DNS_THRU_VPN= " which is enabled by default, the DNSservers pulled from the VPN provider are added as routes through the tunnel, which you can see in the routing tables.
But this only applies to the DNSservers pulled from the VPN provider, not for servers you specify in Static DNS or add in DNSMasq options
So if you specify different servers with no-resolv in DNSMasq options then that servers are used for DNS and those are not routed through the tunnel.
So if you use the no-resolv directive in DNSMasq you have to specify the DNS servers which are pulled from the VPN provider and only those.
But if you do not use "route-noexec" in VPN options then everything would be fine.
If you do use route-noexec and want to use your own DNS servers and not the ones pulled from the VPN provider I can modify the script (well I can try) so that you specify your own DNS servers.
Edit: I made a very crude hack to the script so that you can specify DNS servers of your own, the ones you specify in the script get a route through the tunnel.
Of course you have to set those DNS servers in DNSMAsq options with no-resolv, server=
I only have Windows scripting skills, so use at your own risk (although it seems to work at my router). I hope @Eibgrad will chime in, he is the real guru.
Thank you so much for doing that! I'm really very grateful. I wish I could say that it worked, but sadly not. I can see traffic to the DNS servers specified in the dnsmasq config and script going out via the WAN IP.
I'm almost certain there must be something I've done wrong in the other config somewhere, if not the only other thing I can think of is something about this build on this particular device.
I'm going to set up an old RT-N66U at the weekend and test on that, before I take up any more of anyone's valuable time asking for advice on troubleshooting. If I get it working on the Asus, I can try again on the R7800. If not, then I'm probably doing something wrong in setting up dd-wrt/openvpn.
I fully expect to be coming back shame-faced to explain what setting or config I'd got wrong, but will report back either way.
Just thought I would report back. Short version: I got it working the way I wanted with your script.
Longer version:
I started with a fresh install of the latest Kong build, and made backups of the config at each major step so I could roll back. I checked various settings using shell commands and by looking in files, to see what changing something in the GUI did to the config. And I also read up a bit more extensively on all the dnsmasq and openvpn commands that were being utilised in various bits of config, instead of just a quick skim read.
A few things that didn't I didn't understand which didn't necessarily cause all of the problems, but did slow me down:
As far as I can tell eibgrad's script forces the VPN client onto tun0, even though I had specified tun1 in the vpn client config. This would explain some of the times I just couldn't get any of it working alongside a VPN server, which was set to tun0.
The script adds routes for the DNS servers pushed by the provider in their config, regardless of what you have specified in dnsmasq. However if dnsmasq is set to different servers, those won't route down the VPN (doh!), unless you modify the script as you so kindly did.
Also I think I expected the PBR script to only route DNS queries for PBR clients down the VPN, and other clients would route DNS out the WAN. Clearly this isn't the case and it led to some of the confusion.
Anyway I now have everything set up more or less the way I wanted - PBR clients route down the VPN as expected, and I'm able to use Cloudflare DNS rather than the VPN provider's. DNS queries route down the VPN for all clients, not just PBR clients, but that's fine and at least the VPN'ed clients don't have DNS leaks.
I've tried various configs using the VPN DNS and Cloudflare, and they all work now. I could swear I had tried the same configs at some point earlier on, but there I must have made some mistake somewhere, because it didn't work then and it does now.
I guess I could have lived with the DNS leaks, but at least now I not only have it working, I also understand (mostly) what it's doing.
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Mon Oct 22, 2018 10:17 Post subject:
Glad you got it working.
Regarding your assessment of DNS that is absolutely spot on.
Regarding TUN, the script just uses DDWRT to run the VPN client, DDWRT defaults to using TUN1 for OpenVPN client (and TUN2 for server), In theory you should be able to use something other i.e. TUN0. However in my experience not all firewall rules are then always generated probably a bug somewhere. So just keep it at its default (TUN1) _________________ Routers:Netgear R7000, R6400v1, R6400v2, EA6900 (XvortexCFE), E2000, E1200v1, WRT54GS v1.
Install guide R6400v2, R6700v3,XR300:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=316399 Install guide R7800/XR500:https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=320614 Forum Guide Lines (important read):https://forum.dd-wrt.com/phpBB2/viewtopic.php?t=324087
Cheers. Something - I'm pretty sure it's the PBR script - is appending "dev tun0" to the end of the openvpn.conf in /tmp/openvpnvl. Which threw me for quite a while.
I haven't quite figured out why yet but I'm digging through the code and running config trying to work it out. Linux networking isn't really my area but it's fun to learn something new.
Joined: 18 Mar 2014 Posts: 12889 Location: Netherlands
Posted: Tue Oct 23, 2018 8:17 Post subject:
Hmm that is interesting.
He rebuilds rout-up.sh because he needs the environment variables (like the dev and the IP of the interface and the route) so he could do that.
In that case he will take care of the right firewall rules for TUN0.
Edit: it is used to secure the firewall of the VPN, the VPN is placed on TUN0 and the necessary rules are created for TUN0.
If you do not want that then comment (#) the following rule which you can find under OPTIONS:
Code:
# http://www.dd-wrt.com/phpBB2/viewtopic.php?t=307445
#CONFIG_SECURE_FIREWALL= # uncomment/comment to enable/disable
Yes that script can be used to teach an andvanced masterclass (I will take/need that course)
Thanks, haven't gotten very far with the script yet (too busy at work) so that really helped understand what's going on, plus the thread linked in that comment line has loads of really good info that I've stayed up too late reading.
Will take a deeper dive into the script at the weekend or next week!
