1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Settings up VLANs with differing DNS servers, dnsmasq, and VPN client.

Discussion in 'Tomato Firmware' started by m59peacemaker, Feb 25, 2018.

  1. m59peacemaker

    m59peacemaker New Member Member

    I am trying to set up 3 mostly different local networks, and I am only ever to *almost* get what I am looking for. I have to break something somewhere to make something else work. I've been through all the related posts on this forum, and couldn't find something quite like this. Piecing together the complete system from any of those individual solutions always leads to conflict. Here is what I am trying to do:


    I'm using AdvancedTomato (Tomato Firmware 1.28.0000 -3.5-140 K26ARM USB AIO-64K) on a Netgear R7000.

    I have previously just set my DNS servers to OpenDNS in the easy manner (Basic -> Network -> WAN -> DNS Server -> Manual), and used the `address=` directive of dnsmasq to resolve my dev domain to my local dev machine. The address directive would be applied to all networks, which I'd prefer not to be the case. Now I've setup the DNS servers in dnsmasq, preceded by `no-resolve` to ditch the ISP DNS, so that's one small step forward. Other than the address directive being applied to Home and Guest, those work as desired.

    Now, if I were just dealing with a private LAN/VLAN, I can get that working, but it does conflict with the Home and Guest setup (more on that in a moment). I follow the provider's instructions, I've fiddled with both route-nopull and route-noexec... Redirect through VPN -> From Source IP -> VLAN ip ( And this kinda works. I am currently using route-nopull and Accept DNS configuation = Exclusive. When I switch over to it from Home or Guest, the routing policy seems not to work until I toggle the routing policy off, save, toggle on, save. Then my ip accords with the VPN. But alas, even this buggy situation comes at the expense of not using OpenDNS on the Home and Guest networks, as any attempt to configure that ends up breaking the vpn or leaking my IP. Pretty tough!

    I find the advanced routing stuff very hard to break into from independent studying. I don't think I can get this any closer on my own. Thank you so much for any assistance, and I will pay it forward!

    In case anything should happen to the included image, and for the sake of searchability, the image depicts:
    WiFi - Home -> LAN (br0) -> dnsmasq? * -> OpenDNS (no ISP dns) -> WAN
    WiFi - Guest -> LAN (br1) -> -> OpenDNS (no ISP dns) -> WAN
    WiFi - VPN -> LAN (br2) -> VPN Client -> VPN DNS (no ISP dns) -> WAN
    * resolve dev my-domain com to local machine ip
    Last edited: Feb 25, 2018
  2. eibgrad

    eibgrad Network Guru Member

    It's actually "no-resolv, not "no-resolve" (just in case that syntax error is actually in the config file).

    I can think of several ways to get you close to what you want, but the big problem here is this dependence on *one* local DNS server to solve every problem. DNSMasq is *global* in scope, and so when you try to have it behave differently for different users, you can tie yourself into knots as each change seems to negatively affect something else. And when that happens, you have two choices; live with the limitations that using a single instance of DNSMasq imposes, or use *multiple* instances of DNSMasq. Nothing says you *have* to use only one instance of DNSMasq. That's just a self-imposed limitation.


    Now granted, this approach isn't for everyone. As I said, I can think of ways to still use the single, default instance of DNSMasq and get sorta close. But sometimes using multiple instances proves better. Esp., for example, when you want to prevent local name resolution to some clients and not others. As I said, DNSMasq is, by its very nature, global. It doesn't distinguish among different users at the point of access. So the way to solve that particular problem is force each group of users to have their own uniquely configured DNS server (i.e., instance of DNSMasq).
  3. Sean B.

    Sean B. LI Guru Member

    As you didn't provide what subnets you're using for each bridge, I'll assume br0 = br1 = and br2 =

    To configure clients on the guest network to use OpenDNS servers via DHCP rather than the router, use the dhcp-option directive a long with tag matching:

    Note that the "Intercept DNS" option under Advanced->DHCP/dns must be un-checked for clients to be able to send queries to servers other than dnsmasq.

    This should also fix the issue of clients on the guest network being able to resolve your local domain, as dnsmasq will not be answering their queries. However, an added layer would be to use the localise-queries directive in addition to a host-record directive rather than the address=. If the router's IP on br0 is you would add:

    You can add a short name within the same line if you want dev to resolve the same as dev.my-domain.com:

    The localise-queries directive will have dnsmasq serve local host records dependent on the interface of which the query was received. IE: Clients on interface br0 within the subnet will be served the record for dev.my-domain.com resolving to , where clients on other interfaces/subnets will not.

    As far as the VPN situation, VPN's are not my thing. I would suggest seeing if @eibgrad has any input regarding that matter for you.
  4. Sean B.

    Sean B. LI Guru Member

  5. eibgrad

    eibgrad Network Guru Member

    Here's an example of getting "close" using a single instance of DNSMasq.

    Leave the DNS setting in the OpenVPN client as Disabled.

    Add the following to the OpenVPN client custom config field.

    route-nopull # optional, only if you want to use PBR
    route vpn_gateway # Google DNS via VPN
    route vpn_gateway # Google DNS via VPN
    route net_gateway # OpenDNS via WAN
    route net_gateway # OpenDNS via WAN
    Add the following to DNSMasq.

    server= # Google DNS
    server= # Google DNS
    dhcp-option=tag:br1,6,, # OpenDNS servers for guests
    The net effect is that OpenDNS is always accessed over the WAN. Your ISP's DNS servers are *never* accessed. Everyone except the guests use Google DNS. When the VPN is active, Google DNS is accessed over the VPN.

    Despite this, there are two "flaws". First, when the VPN is active, Google DNS is being access over the VPN, for VPN and non-VPN users alike (not the end of the world for most ppl). But you still have the problem of preventing local name resolution for specific users. Again, DNS doesn't work differently for different users. If anyone has access to local name resolution, then everyone does (at least I've never seen any DNSMasq directive that makes it possible; maybe I've just missed it).
  6. Sean B.

    Sean B. LI Guru Member

    The localise-queries flag for dnsmasq will provide local name resolution segregation between interfaces/subnets based on the interface/subnet the query was received on. Segregation between individual clients on the same interface/subnet is not possible to my knowledge.
    eibgrad likes this.
  7. eibgrad

    eibgrad Network Guru Member

    You learn something new everyday in this business.
  8. m59peacemaker

    m59peacemaker New Member Member

    `no-resolve` was indeed just a typo in this thread, not in my config. I mis-type that just about everytime!

    I had been messing with the dhcp-option for dns servers, to no avail. I don't mind running multiple instances of dnsmasq, if necessary, or if that is the ideal solution. I'm unclear if that is the case, with `localise-queries` being a possible solution. However, I haven't been able to make any progress trying to follow Sean B.'s suggestions. When I put it into practice, the first thing I go for is getting my home network right. So I want to point its dns to OpenDNS, but resolve that local domain. I still can't get both to work without setting it for everybody, breaking the internet, etc. I'll try to reason it out here:

    I want "Intercept DNS port" checked, because I want to control what DNS clients are allowed to use at the router level. Whether I check it or not should just determine whether clients are forced to use the router's DNS, or can decide for themselves. When it isn't checked, the internet still works by default, so I'm assuming the client's by default ask the router, where dnsmasq is running (, which hands that off to the ISP's DNS servers. If use `no-resolv`, then there's nowhere to forward the DNS requests to, so the internet is broken.

    After using `no-resolv`, I need to setup some DNS servers, which I could do for all requests/clients with `server=,`, or I could target each interface individually with `

    If I'm right so far, then I'm good to go on setting up per-interface dns, except that by doing so, dnsmasq would no longer be used by my home network to resolve the local domain to the local ip. So, does this localise-queries and host-record approach allow me to set a network to first try to resolve dns through dnsmasq and then on to OpenDNS if dnsmasq doesn't have the record?

    I am entertaining the idea that I am failing because I am trying to:

    1. globally unset dns servers using no-resolv
    2. set dns per interface

    Whereas it may be ideal to:

    1. globally unset dns server using no-resolv
    2. globally set dns to OpenDNS and with local domain resolution
    3. set dns per interface, at the expense of being able to resolve local domains for that interface, since using `dhcp-option` to set the dns servers for and individual interface would stop that interface from using dnsmasq where the local domain records are.

    If I'm right about #3 there, if I needed to set dns per interface AND resolve local domains for that interface, then I'd need multiple instances of dnsmasq, right?

    This leads to the VPN topic. I am actually using the OpenDNS family filter dns (,208,67.220.123) for the home and guest networks, and that is not friendly for VPNs, of course. With the OpenDNS servers applied in the global way, the OpenVPN client's connection is blocked, so I try the obvious thing: `dhcp-option=tag:br2,option:dns-server,,`, but that makes no discernible difference, I think because the vpn client itself is not on that network, it's just on the router, receiving that global dns, which is the filtered OpenDNS servers. This may be where eibgrad's code block with the `route` configurations come into play. I'm not able to make any progress with that. "vpnrouting: searching gateway for tun11", as usual, presumably because of the OpenDNS filter. Also presuming that "Intercept DNS port" is a problem here, because that stops me from being able to set the vpn client to use different dns, right?

    This is a fun one!
  9. m59peacemaker

    m59peacemaker New Member Member

    Also just noting that in my two given approaches about globally setting DNS or per-interface only, the latter solves some problems, while creating a problem by blocking the vpn. That's exactly why global settings are hardly ever the way to go. While it might take more configuration and more knowledge, it seems like there would be a way to do this that keeps everything isolated, simple, and declarative, wherein configuring one interface would require no thought of consequences to any other. I am betting that will be the multiple dnsmasq instances.
  10. Sean B.

    Sean B. LI Guru Member

    This statement completely contradicts your diagram. It shows Guest Network -> OpenDNS .. fully bypassing dnsmasq ( the router ) which is shown only for the private LAN. As such, the solution I gave you does exactly that, and would require intercept DNS to be turned off because, as should be obvious, clients will not succeed in bypassing dnsmasq for DNS queries if dnsmasq intercepts them.

    These two statements are incorrect:

    1: You need to ignore resolv.conf. As even with a full linux distro, resolv.conf is used by local processes only, as in processes that are running on that physical machine. IE: when you shell into the router and do nslookup, it uses resolv.conf. It plays no role in your network, at all.

    2: When it's not checked, the internet still works because your clients are being configured with a DNS server *other* than dnsmasq ( hint: OpenDNS ) .. and those queries get through and are answered.

    3: Dnsmasq does not " hand off " anything to the ISP's or anyone elses DNS servers. When dnsmasq is acting as the DNS server for your network, it is the only server your network clients are aware of ( intercept dns is only a back-end catch-all to keep queries from going around dnsmasq, mostly by mistake/misconfiguration, and to a lesser level by malicious intent ). When a client sends a DNS query to dnsmasq, dnsmasq will answer it from one of 3 ways. 1: The query matches a host in the routers hosts file, or a specific address= host-record= line in it's configuration. 2: The query has been previously answered by dnsmasq and is still active in it's cache, so it re-sends the cached answer to the client. 3: Neither #1 or #2 apply so dnsmasq sends it's own query to upstream servers ( which servers are dependent on configuration ), upon receiving a response, dnsmasq then forwards that response to the client of which sees the answer as having come from dnsmasq.

    This concept is extremely broken:

    What happens: Break DNS

    Why: When the box for "Use internal DNS" is checked in the GUI, /etc/resolv.conf contains only the line "nameserver" . Which literally means "ask yourself". Any dns queries sent from a process on the router ( IE: you're logged into a shell on the router and do: nslookup google.com ) are sent to the localhost IP.. which means that process is asking dnsmasq.. and dnsmasq handles it in 1 of the 3 ways I described above. When you add no-resolv to dnsmasq config, you're not telling it to ignore resolv.conf... you're telling it to ignore resolv.dnsmasq ( Tomato sets the flag " resolv-file=/etc/resolv.dnsmasq " in /etc/dnsmasq.conf . This is how it separates ISP issued DNS servers when "Use internal DNS" is unchecked, from user-entered DNS servers simultaneously set in the GUI ) . And guess what? That's where the static DNS servers from the GUI go!!! Unless you added server IP's to the custom config box, you have now broken your network DNS.

    What happens: Pointless.

    Why: This is exactly what the static DNS lines in the GUI are for. Except they are stored in /etc/resolv.dnsmasq instead of the dnsmasq.conf ( no, not resolv.conf.. none of this touches resolv.conf ) file.

    What happens: Tell clients to completely bypass dnsmasq/the router for DNS. Works if "intercept DNS" is unchecked, breaks network DNS if "intercept DNS" is checked and no-resolv is set in the custom config, Works if "intercept DNS" is checked and no-resolv is not set.. but is a pointless thing to do.

    Why: Those lines configure what information DNSmasq gives to the network clients during the DHCP exchange. So you've set an option line instructing dnsmasq to tell each client " dont use me, use these servers instead " .

    Overall answer:

    Now that you state you don't want the router bypassed as your diagram implied you did:

    Put the OpenDNS server IP's into the Static DNS section of the GUI, then put:

    Into the custom config box for dnsmasq.

    What it does:

    Dnsmasq will ask OpenDNS for an answer to any queries it cannot answer from methods #1 and #2, and then forward that answer to the clients. This means all network clients on private and guest network are receiving queries answered by OpenDNS but seen by them as coming from dnsmasq.

    If a client from the guest network sends a query for dev.my-domain.com, this answer will fall into method #1.. HOWEVER because of the localise-queries option, dnsmasq will only return this answer if the client who sent the query is located on your private network ( because this is the same interface/subnet that the answer pertains to ) .. and will NOT give this answer if the query came from a client on your guest network 192.168.X.0/24, where X is anything but 1 ( because this interface/subnet is not the interface/subnet the answer pertains to ) .
    Last edited: Feb 28, 2018
  11. m59peacemaker

    m59peacemaker New Member Member

    Ah, I apologize. I didn't mean to communicate with my diagram that I cared whether dnsmasq was involved or not, anywhere along the way on any network. I only pointed it out explicitly on that network with the asterisk to note that I figured I needed to do local domain lookup with dnsmasq; heading in the directionf of X/Y by including my supposed solution in the question itself. Sorry about that.

    It appears I need to unlearn everything and just own that in order to get this the way I want, I'm going to have to develop jr. professional level skills. Time to add this notch to my software developer and sysadmin belt.
  12. Sean B.

    Sean B. LI Guru Member

    Please note I added more to my last post while you where posting a response to it, to conclude its intended explanations.
  13. m59peacemaker

    m59peacemaker New Member Member

    If I set the DNS in the GUI, that is for the whole WAN (unless I am doing it wrong?), and that causes the router to not be able to connect its vpn client because OpenDNS blocks vpns. I either need to find a way to make the client use different dns to connect to the vpn or have the router use different dns if a request originated from its own ip. I'm not sure if that's a thing.
  14. Sean B.

    Sean B. LI Guru Member

    So I assume what I suggested for the other 2 ( non VPN ) networks is working? For the VPN network, you need to be very specific with your statements on DNS servers and which is used when ( over VPN, over WAN ) etc. Are you saying you just need the VPN clients to use some other DNS server so they can resolve the VPN server for connection? Are the clients even the actual VPN clients, or are you making the VPN client connection with the router itself? Do the clients need to use a specific VPN provided DNS server once connected? DNS can be a tangled web once VPNs are involved.
  15. m59peacemaker

    m59peacemaker New Member Member

    Yes, the non VPN stuff works just fine. I am using the VPN client in the Tomato GUI (runs on the router). When dns is set to OpenDNS at the wan level in the router GUI, then that VPN client is blocked from connecting to ipvanish by OpenDNS. The router logs show "searching gateway for tun11". I presume that if it could connect, it would then receive the DNS servers from ipvanish and use those for requests made from devices on the network I am routing through it, as I have the VPN dns option set to "exclusive".
  16. Sean B.

    Sean B. LI Guru Member

    If the domain of the VPN server is "ipvanish.com" for example, then put this in the dnsmasq custom config box:

    This will forward all DNS queries for ipvanish.com and any subdomains thereof ( IE: server.ipvanish.com ) to Google DNS servers instead of OpenDNS.
  17. m59peacemaker

    m59peacemaker New Member Member

    Ah. That makes sense. So, I think that will take care of what I actually need, but it feels disorderly to me, like I am just hitting the right switches rather than building a system, if you get my meaning... If for no other reason than to develop my knowledge, I'd like to explore it a little more. With what I've tried to pick up from you so far, this is the best I can describe it:

    Router's upstream DNS is set to unfiltered openDNS (or just the automatic DNS from ISP, etc)

    Home network uses the router for dns, because I want to use its dnsmasq to point domains to local machines. However, and this is the difficult part to me, I need it to forward all other dns requests to filtered openDNS servers.

    The guest network just uses the OpenDNS servers. If I can get the home network right, I'd like to make the guest network use the router for DNS as well in that same manner. I figure it's better to have it setup so I can route local things on that network, even if I'm not using it.

    On that front, I'm back where I started. Maybe what I'm looking for is multiple instances of dnsmasq, like eibgrad suggested?

    In a dream world, something like this would do it:

    wan (everything not configured to do something different)

    br0 (br0 only)

    br1 (br1 only)

    I get why that is nowhere near how it works, I'm just trying to get the idea across about having fine grain control over things. I think separate instances of dnsmasq per network would let me do just that.
  18. Sean B.

    Sean B. LI Guru Member

    This concept is the foundation on which DNS was built. Ask yourself this.. how would DNS work if every DNS server had to individually be updated for any DNS entry created or changed? Or each server had to have the storage capacity to hold a record for every single globally routable domain/host that exists? Or how long each query would take to get a response while the server digs through all those entries? Not so good right? Now there's more involved when you deal with global servers, things like auth zones etc. But simplified is at the base you have the "root" global servers. Those are the masters of the universe. From there it tiers down the ladder server to server down to the smallest home network router. Now when any of those servers need to anwer a query, they can do it by the methods I explained in my previous post. If the answer doesnt exist in its preconfigured hosts file or existing cache.. the query will be forwarded up the ladder of servers.. until one of them knows what the query resolves to.. or knows that the domain/host has no record. So im not seeing why you feel this is just switch flipping, it's how DNS works.
  19. m59peacemaker

    m59peacemaker New Member Member

    I apologize. I think the way I would speak about software architecture doesn't come across the same way on this topic. It's a question of how the configuration is described, not how it works, what it is, or what it does. I doubt my point comes across there and unfortunately, don't think I'm going to be able to communicate it any better. I appreciate your thoughts, though! I'll keep trying stuff and see what happens.
  20. koitsu

    koitsu Network Guru Member

    Solely in reply to c#17: what you want is understandable and very reasonable. However, dnsmasq is not so good at doing this task (but it is well-integrated with TomatoUSB in several ways, since it's not just as DNS server, but a DHCP server as well). Speaking strictly about DNS separation (of local zones vs. what to delegate upstream on a per-client basis vs. individual interfaces), this is a task better-suited for BIND/named (available in Entware-ng), which is substantially more memory-heavy than dnsmasq, requires you to make your own startup (init) scripts, and does not provide DHCP (i.e. there is no "shim" between TomatoUSB <-> dnsmasq (for DHCP) <-> named), etc..

    I've also talked in the past how dnsmasq has problems with "truly" understanding local DNS queries (ex. shorthand/short names vs. FQDN) and "when" it's appropriate to send them to upstream servers. Once I found it punting queries for local zones (ex. foo.mydomain.lan) to upstream nameservers (this never sat well with me), I stuck to using BIND/named (but not on Tomato -- I run it on a FreeBSD box on my LAN).

    Tomato nor TomatoUSB were ever designed for "complicated" configurations/setups. This isn't your fault (you're a victim of it, if anything!), but the intended goal from the very beginning was for generic end-users who wanted a router that provided abit more insight to things + some more technical capabilities (but not complex), and for their packets to be driven by a Linux-based OS. Sadly, as more and more features started getting added to the firmware (OpenVPN being a big one), adding all the "glue" to make it "user-friendly" while simultaneously providing support for more complex setups never happened.

    Given the data in your initial post, your setup definitely falls under "complicated", which Tomato isn't so good with. Not trying to dissuade your efforts at all, just pointing out that the reason all of this "hurts" so much is due to what I've described here. Some of the complication is OpenVPN. Some of the complication is dnsmasq. Some of the complication is TomatoUSB. This is why you feel like you're "hitting switches" rather than "building a system". It's a router intended for generic end-users with more insights and tweaks/bells/whistles than your run-of-the-mill black-box router firmware, but not intended for complicated network setups (especially VPNs). Mikrotek stuff is much better suited for this, IMO.
  21. m59peacemaker

    m59peacemaker New Member Member

    That makes sense. I've had the growing desire to figure out how to just write shell scripts for all this. GUI stuff is always a bad day to me. I'm just kind of floating out in space on what to write and lacking time to start at square one experimenting in a terminal for hours on in.
  22. koitsu

    koitsu Network Guru Member

    You're going to find "writing shell scripts" painful on TomatoUSB because there is no permanent/persistent filesystem by default, so everything you write/do is lost on reboot. Everything is in ROM, so NVRAM variables are used to store certain data, those things recreated (scripts, etc.) from scratch by the firmware. Embedded devices are very different than, say, a Linux desktop or server distro. TomatoUSB supports USB sticks or USB disks which you can format as ext2/ext3 filesystems and will auto-mount by the firmware, and special filenames in the root directory can be auto-run as shell scripts on mount (router coming up) and unmount (shutdown). Entware-ng, which you can install on said USB stick/disk, provides third-party packages from a third-party source (i.e. not TomatoUSB developers); this may be useful to you to have a better text editor (ex. vim) and some other tools.

    You may also be interested in something like the OpenWRT firmware -- which uses a persistent filesystem, flat text files for configuration setups, packages for additional software, and two choices of web-based GUIs (though in some ways not as nice as TomatoUSB) (or maybe they now only offer one? Don't know). However, OpenWRT's wireless driver support is extremely limited depending on what exact model of router you have (anything from Broadcom = unlikely you'll have working wireless, due to the wireless drivers being binary blobs provided by Broadcom. OpenWRT has a strong open-source requirement, and they use a newer kernel that isn't compatible with those binary blobs).

Share This Page