dnsmasq not respecting subnets

Discussion in 'Tomato Firmware' started by rthur, Apr 26, 2014.

  1. rthur

    rthur Network Newbie Member

    I have two different vlans setup, both using DHCP and their own /24 on Shibby 117 (running on a WRT54GL).
    The first VLAN has a couple DHCP reservations for some services, and tomato serves as a basic dns server to resolve domain names to these DHCP reservations.

    This works fine if a client is part of VLAN that also "contains" these services, but does not work for the second vlan. Instead of querying the nameservers as expected (which would return the external IP in this case), dnsmasq returns the local IP of the service. This IP is on a different VLAN, and a different subnet however, so it's entirely inaccessible.

    Is there a way around this?



    UPDATE: Adding "localise-queries" to my dnsmasq conf (via the web interface) hasn't helped.
    Last edited: Apr 26, 2014
  2. rs232

    rs232 Network Guru Member

    What do you mean by external? The WAN address?
    I'm not sure I fully understand you setup but perhaps the server and host-record directive might help you.
    Also remember the useful log-queries to help you troubleshooting dnsmasq

    Also if you need on VLAN to access another look into the LAN access menu
  3. rthur

    rthur Network Newbie Member

    Sorry, that blob of text wasn't too clear.

    I have two different vlans, which each have their own subnet.


    A web server (example.com) is part of vlan A, and is accessible through the public IP with port forwarding.

    When a client that is part of vlan A attempts to resolve example.com using dnsmasq, it resolves to the local IP (192.168.0.X). This works fine, and is the expected behavior.

    When a client that is part of vlan B attempts to resolve example.com also using dnsmasq, it resolves to the local IP (192.168.0.X). This doesn't work as the server isn't accessible from the other vlan - I would like dnsmasq to realize the client and the server are on a different subnet, and to forward the query on to the nameservers (which would in turn resolve example.com to the public facing IP).

    From my understanding localise-queries should do this, but it doesn't seem to work. I'll take a look at the other directives you mentioned.


  4. jerrm

    jerrm Network Guru Member

    Localise-queries would not cause a query to be forwarded.

    Why not just enable access to the server across vlans?
  5. rs232

    rs232 Network Guru Member

    I can think of two ways and both don't include dnsmasq modifications

    1) I think your best bet is to allow routing on port 80 from VLAN2 to VLAN1 (manually via iptables)
    Find the position of the DROP all rule in the forward table
    iptables -L FORWARD --line-numbers -v -n | grep "DROP  all  --  br0  br1"
    Insert a rule above what you've found

    iptables -I FORWARD 7 -i br1 -o br0 -p tcp --dport 80 -j ACCEPT
    (I used position 7, br1 and br0 this might or might not work in your system)

    2) Another option would be to forget about dnsmasq and try the to set NAT Loopback instead (not my favourite option though).
    Last edited: Apr 26, 2014
  6. rthur

    rthur Network Newbie Member

    Thanks for all the replies!

    I wanted to try and avoid enabling access to the server across the vlans as in reality there's more than one server, and I wanted to have a more generic mechanism. Is there really no way to have dnsmasq not return an ip that a given client cannot access?

    I'll play around with iptables - thanks for the detailed explanations!
  7. jerrm

    jerrm Network Guru Member

    dnsmasq has no way to know what is reachable and what isn't. The gui can allow access to only one IP between vlans. If you want to narrow to a single port then add a manual rule as suggested.
    koitsu likes this.
  8. darkknight93

    darkknight93 Networkin' Nut Member

    Running two dnsmasq instances for each vlan one would solve your issue. But due tomato never was planned two run in two vlans.. Much work to do. Have tried Different router os yet?
  9. jerrm

    jerrm Network Guru Member

    A second dnsmaq instance isn't likely to help. I doubt what he wants to do would work with loopback enabled. The rules blocking vlan1 to vlan2 would likely still block the traffic.
  10. rs232

    rs232 Network Guru Member

    I think you need to take dnsmasq out of the equation as returning the LAN IP is the correct behaviour

    I don't get why you would not allow port 80 between VLANs but you would allow port 80 via the WAN. Is there any difference? Accessing port 80 from the WAN would indeed achieve exactly the same result: forward the request to the webservers on VLAN1. BTW the iptables command provided gives you automatically access to all the webservers on port 80 sitting on VLAN1 from any host VLAN2. If you want to restrict source/destination IP you can add it to the iptable command.

  11. Edrikk

    Edrikk Network Guru Member

    I don't think allowing port 80 from LAN would work for him, as servers like Apache need the host name to allow virtual hosts (multiple sites on one Apache instance) to work as far as I recall...
  12. rs232

    rs232 Network Guru Member

    host name (host-headers as defined by http 1.1) have nothing to do with the source IP/destination IP. For reference the destination host is part of the http GET request.
    I haven't tested the above scenario but I'm pretty sure it will work
  13. Edrikk

    Edrikk Network Guru Member

    Although you're right, unless I'm misreading what was suggested above is to let LAN port 80 cross subnets. Meaning the users would have to type for example from type: instead of http://www.blah.com or http://www.num2.com

    In this scenario, Apache won't know which site to pull, and will pull the default site.
    koitsu likes this.
  14. rs232

    rs232 Network Guru Member

    As understand he does get the correct LAN IP when resolving names but he would like the WAN IP instead when trying to resolve from VLAN2. So no, he does call the webserver via FQDN.
    If http://www.example.com gives him (in vlan1) where he would like to get the WAN IP instead.
    What I was trying to explain is that getting the LAN IP address when resolving is perfectly normal and wanted. Getting the WAN IP is possible but it would not allow VLAN2 to communicate with VLAN1 via the WAN interface!
    I guess playing with post-routing and NAT you could even get a slow cumbersome double routing of sort, but why?
    With that iptable command provided he would solve everything with one line of code without compromising security.
  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