DNS not respecting VLAN?

Discussion in 'Tomato Firmware' started by mcbsys, Jun 26, 2012.

  1. mcbsys

    mcbsys Networkin' Nut Member


    I've set up a guest VLAN using tomato-E2000-NVRAM60K-1.28.4407.1MIPSR2-Toastman-VLAN-RT-VPN.bin. I blogged about my setup here.

    DHCP is enabled for the primary VLAN on br0 and the guest VLAN on br1. br0 is a wired network that includes a DNS server and a web server.

    DNS lists first an in-house server on br0, then two external servers.

    As usual with this config, the internal DNS server requires a special pointer for br0 users to be able to seamlessly visit the locally-hosted web server. So if the web server is at, the in-house DNS server points mydomain.com directly to

    This is causing problems on br1. If a br1 user visits mydomain.com, they get an invalid page message.

    This would seem to indicate that in spite of the VLAN separation, the router is passing DNS queries from br1 to br0. The internal server tells the client to look for mydomain.com on, but the client on br1 can't do that because port 80 traffic is blocked between the VLANs.

    Is there a way to either block DNS traffic between the VLANs, or to configure a separate DNS server list for br1?

  2. teaman

    teaman LI Guru Member

    Hi there!

    First of all - there's something we should keep in mind here: there's no 'right' or 'wrong' - think... 'just different' ;)

    Hope the following thoughts/ideas help clarify things a bit when/if we're dealing with more than one LAN bridge configured on your Tomato router:

    Have a look at /etc/dnsmasq.conf - you'll notice some "interface=brX" directives for each of your (configured) LAN bridges. If DHCP is supposed to be disabled on a particular LAN bridge, you should also have a line like "no-dhcp-interface=brX" for those. This tell us two things: a) dnsmasq might not be configured to serve DHCP on any/all your LAN bridges, but... b) dnsmasq will be ready/available to answer DNS requests on any/all your brX interfaces anyways. The reason behind this decision? So any devices/clients on any of your brX could use your router as the DNS server, regardless of any LAN access/restrictions that might be in place.

    By default (historically), the firewall script in Tomato should accept anything coming from LAN bridge (that is, when only one LAN bridge is supported - and/or on non-modded versions). I've tried to follow this very same idea when extending/implementing the MultiLAN mod (aka. VLAN-GUI): we should still accept any/all traffic coming from all LAN bridges and forward it, unless the target is another of our LAN bridges (by default, traffic should be isolated/unreachable from each other unless specified, but should flow freely to the internet, etc...)

    Then, please have a look at the Advanced: LAN Access page (advanced-access.asp) and how any new/extra rules in there (main table) may affect/change the rules near the FORWARD section of /etc/iptables: since this 'LAN isolation' thingie is based on iptables rules, the 'order' of those rules will match is also important (therefore, the "-A FORWARD -i brX -j ACCEPT" rules should be located/placed/created after their "-A FORWARD -i brX -o brX -j DROP" counterparts on /etc/iptables).

    Hm... do you mean 'timeout', by any chance?

    Nopes - I'm afraid that's not the case. Dnsmasq running on the router is simply trying to do it's best and saying 'AFAIK, is the IP address of the address you've asked: mydomain.com'.

    Also... not entirely accurate: this is not just about traffic directed to port 80, this is about the source/incoming and target/outgoing LAN bridges (brX), not VLANs (different LAN/brX ifaces do happen to sit/be in different VLANs, but let's not put those apples/oranges in the same basket).

    There could be many ways to do such things!

    Try the Advanced/LAN Access page: you could create a rule allowing devices sitting on your br1 to reach just that particular IP on br0 (sorry, the GUI is not designed to allow/filter out specific ports, only IPs, restricted to IPv4).

    Another option would be adding this new/extra iptables rule/command via the Admin/Scripts page (Firewall script, on admin-scripts.asp).

    Yet another option... could be... (this one just occurred to me - never tested - but should work): go to the Advanced/DHCP/DNS page (advanced-dhcpdns.asp) and include another 'custom config' directive like this one and DHCP clients should get an alternative DNS server (untested!):
    Here's a (possibly incomplete) list of dhcp-options that could be configured:

    As you can see... endless possibilities ;)

  3. mcbsys

    mcbsys Networkin' Nut Member


    Thanks for your detailed reply.

    First maybe a little more background on what I wish it would do.

    Before I had a Tomato router, I had two routers > connected to a simple switch > connected to a single DSL modem. Our ISP can give us multiple fixed IP addresses through the same DSL modem, so each router had its own external IP address.

    - Router 1, 192.168.1.x, for the internal (wired) network listed the internal DNS server first.
    - Router 2, 10.1.1.x, for the public (wireless) network did not list the internal DNS server; it just routed everything to the Internet.

    With this setup, if someone on the guest network (Router 2) tries to access the web server on the internal network (Router 1), it works exactly as it would work for someone outside the office: from external DNS servers, they get the public IP of Router 1, and if Router 1 forwarding inbound port 80, the web server gets the traffic. Basically it goes out to the Internet and then back in.

    So with Tomato, really what I want is for the VLAN 2 to not have direct access to VLAN 1. All traffic (including DNS) from VLAN 2 should go "out" then only come back "in" to VLAN 1 if the ports are forwarded.

    Your pointer to /etc/dnsmasq.conf is helpful. Here it is:
    As you can see, the DNS server for br1 is already set up and "incorrectly" includes a reference to the DNS server that is only available on br0. (The current Tomato interface only allows configuring one list of static DNS servers, which is apparently shared by all bridges.)

    So the first DNS server will never be reachable from VLAN 2. I thought that if a DNS server was unreachable, it would just use the next DNS sever. But maybe this is causing the web page request to time out.

    In the Dnsmasq Custom configuration, I tried adding a shorter DNS list for br1, omitting the internal server:
    But that left the old and new entries in dnsmasq.conf, and the internal server is still provided to the users on the guest network.

    Next I tried setting the static DNS servers to in the GUI, then using the above line for setting the DNS servers. This seemed to solve the DNS issue: now, the guest network only gets the short DNS list, so it gets the router's public IP address when trying to browse the local web site. However the guest network still cannot reach the web server on VLAN 1: "Cannot find server or DNS Error".

    I have to put this aside for now and do some other work. We have a workaround for now--let the user connect to the wired LAN--but it would be nice if wireless guests at the location could visit the web site hosted at the location.

  4. teaman

    teaman LI Guru Member

    So - you had 2 routers handling traffic between 3 'zones', right?

    - WAN
    - guest LAN (
    - wired LAN + servers (

    May I suggest a slightly different network design?

    - br0 - VLAN2 - workstations/primary wifi/LAN (
    - br1 - VLAN3 - servers (
    - br2 - VLAN3 - guest wifi/LAN (
    - br3 - VLAN1 - management (anything else, useful when used in trunks, etc...)

    Then, it would be a matter of adjusting/setting up some rules in Advanced/LAN Access - that is, I'm presuming your 'servers' and 'workstations' are currently assigned to the upper/lower 'halves' of your existing LAN ;)
  5. mcbsys

    mcbsys Networkin' Nut Member

    Thanks for the suggestion. It would require a re-design since I've used small blocks of IP addresses for different function (the .140s are phones and PBX, copier is maybe .125). If it becomes imperative for in-house guest users to browse the local web site, I will return to this for further consideration.

  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.
    Dismiss Notice