Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Tue Sep 03, 2019 14:39 Post subject:
anon_me wrote:
How can I push the VPN DNS client through to the single VPN LAN client without effecting the other non-VPN LAN clients?
I did see the comment about "Optional DNS Target" but this is an Ethernet client nor a Wireless client and I'm struggling to find the equivalent place for the Ethernet client.
Hi again... What I've seen in my system is that the DNS server pushed by my vpn provider only started appearing in /tmp/resolv.dnsmasq, which seems to be what you are after, in very recent dd-wrt releases. I'm seeing it now in 40784, and I'm pretty sure I did not see it in 39144, so maybe that brackets the release-number range for you.
Because I want to keep my own DNS system going only through DNSCrypt, I actually cannot use /tmp/resolv.dnsmasq myself, so that has led me to an alternative, though a clumsy one. Focusing here on only the parts that seem relevant to you, I split my LAN ports into two VLANs, assign one to br0 and create a new bridge br1 for the other (to which I also assign one VAP, but you could have just the one LAN port on it). Bridge br1 is then set up as a separate subnet. I give it its own dhcp server in the "Multiple DHCP Server" section at the bottom of GUI>Setup>Networking, and -- and this is what seems of potential use to you if you can stomach all this configuration awkwardness -- just a little higher up on that same page, there is a "Network Configuration br1" section where there is indeed a spot for "Optional DNS Target".
Setting up VLANs, however, is both tricky and very, very hardware specific. There is a link in my signature to the forum thread for VLANs on the dual-cpu Linksys WRTblah routers like mine, which are configured using swconfig commands in Startup Commands. There is also a good deal scattered across years of forum and wiki posts about using nvram commands to set up VLANs on routers with Broadcom hardware. In very recent dd-wrt releases, a new GUI>Setup>SwitchConfig tab has appeared that I'm guessing, from the look of it, is just a convenient GUI interface to the same nvram setup. (It's pretty clear that it's useless re the swconfig details for my WRTblah router.)
Again, finding a recent release that handles the "push" business from your vpn provider would certainly be cleaner. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
I will go the upgrade route. My main concern with an upgrade is potentially having to re-configure the entire router after upgrade as the doc seems to suggest doing a full reset before / after and of course I won't be able to re-load my config from a previous firmware version.
Have you found resets are actually necessary when doing an upgrade or is it more of a precaution to CYA?
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Tue Sep 03, 2019 16:05 Post subject:
anon_me wrote:
That's all. I will go the upgrade route. My main concern with an upgrade was potentially having to re-configure the entire router after upgrade as the doc seems to suggest doing a full reset before / after and of course I won't be able to re-load my config from a previous firmware version.
Have you found resets are actually necessary when doing an upgrade or is it more of a precaution to CYA?
The usual dire warnings that one must reset when upgrading seem to come from the Netgear crowd, to be frank, though I could be wrong. For our Marvell routers, I don't reset, and neither do at least some others who do far more upgrades than I do.
For my WRT1900ACSv2 routers, here are my steps.
I back up the config before flashing, just in case I need to revert.
If I care what partition I flash in, in the CLI I do ubootenv get boot_part | tail -1 to identify the current boot partition.
Flashing takes place to the partition opposite the current boot partition, so if for example I want to flash partition 1 and my boot partition is currently partition 1, I reset the boot partition to 2 with ubootenv set boot_part 2.
Then without rebooting first, I do the webflash to upgrade, withoutrequesting a reset.
I wait a full 90 sec before touching anything. The current nvram config is kept. I have never needed to reset the config and start over. My config is complicated enough that it would take a day, and I don't want to go there unless I absolutely have to. But avoiding the reset has never been a problem, though after booting I do go through the GUI to see that everything seems OK. Occasionally I have found things that changed (options that got unchecked or unused windows that acquired junk entries) and needed to be changed back, but typically everything is fine and no edits are required.
I back up the config again, in case I need later to get back to this just-flashed point.
Of course sometimes new choices appear that need a little thought or research. That last step is easier if I took the precaution before flashing of taking photos of the GUI screen with my phone (easier than dealing with screenshots or browser saves). _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
Joined: 04 Aug 2018 Posts: 1447 Location: Appalachian mountains, USA
Posted: Tue Sep 03, 2019 17:56 Post subject:
anon_me wrote:
Great info thanks. I run a D-Link DIR-859 and no idea if it has separate partitions. Will have a look.
Sorry, anon_me... Somehow I assumed (because Marvell forum?) you were on a two-partition WRTblah router. I'm guessing the ubootenv... commands I mention are specific to the WRTs and won't actually apply to you. My experiences re not needing a reset may also be of minimal relevance, as the webflash procedure leaving the nvram contents in place is also a WRT thing. Not sure it will be the same for you at all. You need to find out what owners of your model are experiencing.
Good luck. _________________ 2x Netgear XR500 and 3x Linksys WRT1900ACSv2 on 53544: VLANs, VAPs, NAS, station mode, OpenVPN client (AirVPN), wireguard server (AirVPN port forward) and clients (AzireVPN, AirVPN, private), 3 DNSCrypt providers via VPN.
I found a script on that thread by a freaking genuis
It handles the routing between the wan and vpn ... At the end of the day it allows me to exclude certain ips to not use the vpn, like my directv boxes without breaking remote access and my openvpn server ... The script is a bit advanced to setup you need either a hard drive or usb to mount to /jffs to get it working but once set up and the rules section i opted to leave the tunnel forwarding everything excluding only a few devices, and it also used the expressvpn dns properly whereas pbr was not, anyway if anyone runs into the same issue look at the aforementioned post
The newer releases add the pushed DNS servers to resolve.dnsmasq
To clarify does this only effect VPN clients or will all clients receive the pushed VPN DNS server? The DNS servers in question will only work when connected to the VPN so don't want my other clients to either have slowdowns because it's trying to connect to the inaccessible VPN DNS or to fail entirely on some level. Not sure if that would be the case or not, just want to clarify.
Joined: 18 Mar 2014 Posts: 12915 Location: Netherlands
Posted: Mon Sep 09, 2019 6:59 Post subject:
anon_me wrote:
egc wrote:
The newer releases add the pushed DNS servers to resolve.dnsmasq
To clarify does this only effect VPN clients or will all clients receive the pushed VPN DNS server? The DNS servers in question will only work when connected to the VPN so don't want my other clients to either have slowdowns because it's trying to connect to the inaccessible VPN DNS or to fail entirely on some level. Not sure if that would be the case or not, just want to clarify.
Newer builds use the DNS servers pushed from your VPN provider.
If you do not want that then add the following to the Additional Config of the VPN:
pull-filter ignore "dhcp-option DNS"
Things start to get complicated if you are using Policy Based Routing.
The DDWRT implementation does this by using "route-noexec" that will prevent the DNS servers from your VPN provider being pushed.
For more information see my signature at the bottom of this posting for "Simple PBR script" also have a look at the second posting of that thread regarding DNS leaks.
The easiest solution is sometimes just to use the no-resolv directive for DNSMasq and specify the DNS servers DNSMasq has to use.
But some caveats
By default all clients VPN and non VPN use the same DNS server unless you specify otherwise.
All clients VPN and non VPN can use the DNS server from the VPN provider but only if this server is publicly availabe, if not then static routing is needed to create a route for the DNS server via the VPN. _________________ 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
I have a WRT32X running VPN, through openvpn, Ive subscribed to a vpn service (expressvpn) got everything working including Policy Based Routing, my last step is getting the dns to use the vpn's dns provided when the tunnel is created, If I do not use pbr, this function works but it breaks remote access to my router so its not a viable option at this time, does anyone know of a script that can obtain the VPN's DNS server when the connection is established and forward it to the the addresses used in PBR?
I was exactly in your situation - wanted to connect to a VPN server using PBR on my router, and at the same time, use VPN provided DNS.
I'm providing my solution below - only one caveat - I'm hard-coding my VPN's DNS server, more scripting can be done to find and use it on the fly, but unless my VPN's DNS server keeps on changing, that will be an overkill.
This solution specifically deals with the problem of sending DNS requests over VPN (and thus avoiding DNS leaks).
The following takes care of the problem when using PBR, but will work when there is no PBR as well.
Just to reiterate an important point, with PBR, the router itself remains off the VPN (along with its dnsmasq daemon).
This means that any PBR client that was using dnsmasq as its DNS server will continue to have its DNS requests NOT going through VPN.
One way to deal with this is to use some other DNS servers (than dnsmasq) on the PBR clients.
This can be done by having these commands in Additional DNSMasq Options (for each of your PBR clients):
With these, irrespective of other dnsmasq settings, your PBR clients will always use these DNS servers.
If OpenVPN client is running on your router, DNS requests to these servers will be routed through the VPN (like every other request).
It's important to use only public DNS servers here so that even when OpenVPN client is not running, DNS lookups work.
With this, route command should not be needed but if needed, the following can be added to the OpenVPN client's config file:
Or the same can be added with "push" to the OpenVPN server's config file.
My problem was even bigger - my PBR clients were dynamic, i.e. I needed the ability to start and stop OpenVPN client on the router - at my wish - so that one or more of my LAN clients can connect to remote VPN server via the OpenVPN client running on the router.
How I did this is another story, but in this case - before starting OpenVPN client - I wanted my clients, like my any other LAN client, to use dnsmasq on the router as their DNS server - just so that local LAN resolution works and I've more control over my clients.
The problem is how to tell the PBR clients - just when the OpenVPN client starts - to now use different DNS servers (than dnsmasq)!
One way is to modify dnsmasq.conf (whenever OpenVPN client starts) with dhcp-host and dhcp-option statements like above - now having new DNS server(s), restart dnsmasq and force the PBR clients to flush dns.
Not a simple task (and all this needed to be undone every time OpenVPN client is shut down)!
I chose another simpler solution - just add iptables rules like the ones stated below through the route-up script (this script is fired whenever OpenVPN client starts and connects successfully the remote VPN server).
With these, any DNS lookup packets from the PBR clients will be intercepted and sent to the desired DNS server.
Code:
iptables -t nat -A PREROUTING -s <PBR_client_IP> -p udp --dport 53 -j DNAT --to <public_or_private_DNS_Server_IP> # can even use the DNS server used by the remote VPN server!
iptables -t nat -A PREROUTING -s <PBR_client_IP> -p tcp --dport 53 -j DNAT --to <public_or_private_DNS_Server_IP>
One big advantage is that these rules supersede other settings such as the DNS servers configured manually on the PBR clients or the ones set through Additional DNSMasq Options.
Remember to remove these rules using route-pre-down script (on shutting down OpenVPN client).
This works seamlessly and instantaneously, and furthermore we are saved from fiddling with dnsmasq and its options.
