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

seperate DNS for vlan (br1) in Multible SSID

Discussion in 'Tomato Firmware' started by zong, Apr 9, 2013.

  1. zong

    zong Serious Server Member

    I asked this question also direct to some forum members but was asked to better open a thread.

    I build up an running Guest VLAN on br1
    http://imageshack.us/a/img850/301/vlanx.png

    As I used DHCP enabled on b1 /under LAN settings
    http://imageshack.us/a/img835/4445/basicqp.png

    As mentioned working fine on my ASUS N16 (Shibby 106 or Victek RAF)
    ---
    I used the "guest VLAN" for my kids and want to use an SEPERATE DNS Server for them.
    My normal DNS is configured as 8.8.8.8 and 8.8.4.4.

    For the "guest network" I want an restricted DNS like TOPDNS.ch (109.73.52.11 and 109.73.52.12)

    I found this in ddwrt-forum and ask for your help.
    DNSmasq:
    interface=br1
    dhcp-option=br1,3,192.168.2.1
    dhcp-option=br1,6,109.73.52.11,109.73.52.12
    dhcp-range=br1,192.168.2.100,192.168.2.199,255.255.255.0,12h

    1) not sure if working (should be but under advanced/DNSmasq)
    2) not clear if I need to DISABLE the DHCP for b1 /under LAN settings in GUI
    3) maybe only "dhcp-option=br1,6,109.73.52.11,109.73.52.12" would work if DHCP to keep "enabled"

    any idea -or maybe someone has a different solution already checked
    br zong
     
  2. darkknight93

    darkknight93 Networkin' Nut Member

    My configuration for my DMZ is following:
    DHCP enabled in Lan - Basic Settings for br0 and br1

    In Advanced->Dns/DHCP Settings in the advanced configuration box I'm using:
    #br1 Configs
    dhcp-option=br1,6,8.8.8.8,8.8.4.4
    Option 6 means DNS Server - so in your case it woudl be:

    "dhcp-option=br1,6,109.73.52.11,109.73.52.12"

    As soon as you disable DHCP Services for br1 on the Basic Settings page, dnsmasq will be deactived for this Bridge (br1)
    But the scripts in advanced configuration overides that - so using
    "dhcp-option=br1,3,192.168.2.1
    dhcp-range=br1,192.168.2.100,192.168.2.199,255.255.255.0,12h"
    re-enables it
    In short: Just leave DHCP in Basic Settings online ;)
     
  3. RDHLLC

    RDHLLC Serious Server Member

    Guys, this topic is being actively discussed in detail on THIS THREAD.

    Basically, DNSmasq was updated and this broke the ability to do what you are looking for. Note: this only applys if you are NOT using "Use Internal DNS" option (unchecked), otherwise you can simply enable dhcp for the vlan, and then define "dhcp-option=br1,6,..."
     
  4. gfunkdave

    gfunkdave LI Guru Member

    You don't need the interface line. That just tells DNSMasq to listen on the given interfaces and provide DHCP/DNS service. It's already in the auto-generated configuration file.

    All you need to do is add one line to the Advanced config box under Advanced -> DHCP/DNS:

    Code:
    dhcp-option=br1,6,109.73.52.11,109.73.52.12
    
    But only in Shibby. Toastman works fine.
     
  5. darkknight93

    darkknight93 Networkin' Nut Member

    thanks for your Input - i upgraded to shibbys 108 yesterday and a few minutes ago i was surprised my config does not work anymore :eek:
     
  6. philess

    philess Networkin' Nut Member

    I am using simple iptables rules for exactly the same thing:

    Code:
    iptables -t nat -I PREROUTING -i br1 -p udp --dport 53 -j DNAT --to 208.67.222.222
    iptables -t nat -I PREROUTING -i br1 -p tcp --dport 53 -j DNAT --to 208.67.222.222
    br1 is my Guest-(W)LAN, forced to use OpenDNS. I have my standard DNS in Basic/Network
    set to use Google, and in Advanced/DNS i have "Intercept DNS" disabled.
    So all DNS requests from br1 are sent to OpenDNS, regardless what DNS they have set in their
    client. And all clients on br0 can use whatever Provider they want, or what DHCP gives them.

    Just a little reminder, depending how clever your kids are, if you give out two different DNS
    servers over DHCP, they can set their PC to use a static IP and a different DNS and they
    have uncensored internet again. Just fyi.

    Same topic: http://www.linksysinfo.org/index.php?threads/force-guest-network-to-use-opendns.68392/
     
  7. zong

    zong Serious Server Member

    @Phil: thx. Where exactly to put the #iptables command and in case "both scenario" work what is better.

    PS: clever kid.
    I propose to setup a rule (access restriction)to all clients /exept to some MAC-Adess to block TCP/UDP Port 53 should STOP also this scenario - or ?
     
  8. philess

    philess Networkin' Nut Member

    iptables lines go to Administratio/Scripts/Firewall.

    If you want to make exceptions to that rule, you need to be more specific in the rule itself etc.
    For example, not use -i br1 but --src-ip 192.168.5.100 etc.. i am not that good with iptables myself,
    but it sure is possible to set all your kids on one DNS, and some MACs to another.
    But i think MACs directly in iptables is not possible, you need to route the IPs and
    in DNS/DHCP settings you could restrict that MAC to only one IP so nobody else could use
    it (theoretically).

    I would recommend just seperating two networks, br0 and br1. Different DNS for each, and thats it.
     
  9. zong

    zong Serious Server Member

    thx - will try with the rules. I started to add the #iptables to see what will happen. Maybe come back tomorrow.
    What would happen in case the rerouted DNSserver is down. As by this scenario I do not see an alternative DNS link. Will it fail -or go back to "normal" DNS as defined before rerouting
     
  10. philess

    philess Networkin' Nut Member

    Sorry, i have edited my older post, it must be iptables ... without the # in front.

    If the DNS is down, there is nothing checking for it and it wont work. Setting up a backup
    DNS this way is maybe possible but way too complicated for me.

    Quick google gave me this as an example (WONT work for you)
    Code:
    iptables -t mangle -A POSTROUTING -o eth1 -j MARK –set-mark 1
    iptables -t mangle -A POSTROUTING -o eth2 -j MARK –set-mark 2
    By using MARK you sent the first packet to the first DNS, then the next one to DNS #2, then to #1 again, etc.
    If one server is down, the client (PC) should retry asking for DNS again (i hope) and then it would be sent
    to the other server, which hopefully is not down at the same time. I havent tested this tho.

    Might be helpful: http://www.diegolima.org/wordpress/?p=36
     
  11. Monk E. Boy

    Monk E. Boy Network Guru Member

    This might work, albeit with a 50/50 chance of it going to DNS server 1 vs. DNS server 2 and being completely random in which packets are resolved by which DNS server.

    Code:
    iptables -t nat -I PREROUTING -i br1 -p udp --dport 53 -m state –state new -j DNAT --to 208.67.222.222
    iptables -t nat -I PREROUTING -i br1 -p tdp --dport 53 -m state –state new -j DNAT --to 208.67.222.222
    iptables -t nat -I PREROUTING -i br1 -p udp --dport 53 -m state –state new -m statistic –mode random –probability 0,5 -j DNAT --to 208.67.220.220
    iptables -t nat -I PREROUTING -i br1 -p tdp --dport 53 -m state –state new -m statistic –mode random –probability 0,5 -j DNAT --to 208.67.220.220
    If you want a third server, you would change the probability to 0,33 and create a third pair of rules similar to the last pair.

    This isn't tested, please don't yell at me if your system goes straight to hell, definitely don't stick this in scripts/firewall before testing it live over a ssh/telnet session (so you can reboot the router back to a working state if it all goes horribly wrong). The state new bit (-m state –state new) might need to be removed since we're basically intercepting packets.

    Ideally you should just plop some form of DNS server on the network that can resolve addresses normally (allow port 53 traffic from it, redirect all other port 53 traffic through the firewall to it) and perform round robin operations, not to mention caching, with a lot less quirkiness. Heck, buy a used router, don't even have to use it as an access point, just use it for DNSMasq. It's bound to work better.

    Also there are third party DNS solutions that don't run over port 53, if you really want to block a client's ability to bypass DNS blocks you will need to block access to those domains and/or ports. For example dns2go uses port 1227.
     
    philess likes this.
  12. RDHLLC

    RDHLLC Serious Server Member

    There is another option, disable DHCP for the interface, add your custom options to dnsmasq config in GUI, then use a bash script to delete the "-no-dhcp-interface=br[n]" line from the dnsmasq.conf, stop the dnsmasq service and launch it as a daemon. Messy but it works.
     
  13. zong

    zong Serious Server Member

    thx guys - a lot of good responses.
    I can confirm "gfunkdave" with "dhcp-option=br1,6,109.73.52.11,109.73.52.12" is working on my N16 with latest RAF firmware (older DNSmasq). For the "guest network" on "br1" I have now a different DNS-server. On top I block port 53 (src) to clients (some exceptions defined) within Access Restriction rule (not iptables direct)
     
  14. gfunkdave

    gfunkdave LI Guru Member

    Cool. philless's post here looks also pretty elegant. You'd just need to add his udp rule - DNS service is all udp. The tcp rule is superfluous. That has the advantage of doing in one line of code what your are doing with a combination of access restrictions and the dhcp-option line.
     
    philess likes this.
  15. zong

    zong Serious Server Member

    I see :)
    Final question: will "dhcp-option" really force DNS request sending to the new DNS for br1 ? (or only optional)
    dhcp-option=br1,6,xxx,yyy

    Reason: I noticed some homepages been not blocked I would expected for the new DNS. Not jet time to digg into this.
     
  16. philess

    philess Networkin' Nut Member

    I suppose it can happen that if the DNS entry for that specific site is already in the routers DNS cache, that it could reply to it instead of redirecting it to the desired other DNS provider. Can happen, but i think in reality not really often. Unless you and the guests are "trying" to browse the same websites all the time, then maybe the cache could become a problem.

    Also, when testing this now, make sure you flush your DNS cache on your client before actually testing if you can reach a site etc.

    Edit: dhcp-option is no "force" at all. It will simply reply to a DHCP request with "hey guess what, i can give you DNS service at IP x.x.x.x" and the client may use that. But nothing is stopping someone from ignoring that and using a different DNS on his client PC to circumvent this. Hence why redirecting port 53 (DNS) requests by iptables is a better solution, or addition. Even if someone ignores the DHCP given DNS and tries to use his own setting, the requests over port 53 will still get redirected to whatever DNS server you want.

    Only way out of that would be using a DNS provider that is not using the standard port 53, as pointed out above. But there are almost always ways to circumvent a "access restriction". In my opinion, the rare chance that someone really would be clever enough to use a non-53 DNS provider to get to his sites... it is very unlikely. You could block ALL ports and only allow 53 and browsing, that would block some other providers. But then again, i think it would be possible to find a DNS provider that is using port 80, and if you block that, there is no point in providing internet access at all then.
     
  17. Monk E. Boy

    Monk E. Boy Network Guru Member

    Sadly TCP is required for DNSSEC support.

    http://www.networkworld.com/community/blog/allow-both-tcp-and-udp-port-53-your-dns-serve

    DNSMasq can serve as a DNSSEC proxy with the --proxy-dnssec option, though there's security caveats to using it.

    It will not force clients to use those addresses, during DHCP it will simply hand out those DNS addresses to br1 clients. Clients could still configure their clients with custom DNS servers. Intercepting DNS packets via iptables is the only realistic way of blocking them from using custom DNS servers.

    I bet someone could create a rule on the FORWARD table to reject or drop 53/UDP packets from the naughty clients instead of catching both good and bad on PREROUTING. Or insert a final rule stating that if 53/UDP is talking to the router that its allowed traffic. If you enable the DNSSEC proxy option in DNSMasq you'd need a TCP rule too. Like, ummm...

    Code:
    iptables -t nat -I PREROUTING -i br1 -p udp --dport 53 -d type.router.ip.here -j ACCEPT
    iptables -t nat -I PREROUTING -i br1 -p tcp --dport 53 -d type.router.ip.here -j ACCEPT
     
  18. Monk E. Boy

    Monk E. Boy Network Guru Member

    Yeah, that's what I thought too, but kids have a way of talking to other kids and sharing their deviousness until suddenly you have huge numbers of kids doing it. Port 80 is fairly simple though, just implement a HTTP proxy server and block direct port 80 access except from the proxy server's IP.

    As a general rule its best to start simple and work your way up to crazier and crazier controls in response to crazier and crazier acts. I don't think iptables is particularly crazy, but getting a proxy server up would take some real effort.
     
    philess likes this.
  19. RDHLLC

    RDHLLC Serious Server Member

    I find the idea of forcing use of a specific DNS using iptables is a good idea. Did anyone try the

    suggestion offered by Monk E. Boy vs the

    suggested by philess?
     
  20. philess

    philess Networkin' Nut Member

    They are both based on the same principle, Monk E. Boy added the probability tho. I havent
    tested that part myself yet. But the simpler two-liner version i am using that for weeks now
    without problems.
     

Share This Page