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

Restrict Access to Web UI on Guest WiFi

Discussion in 'Tomato Firmware' started by vertigo235, Apr 4, 2013.

  1. vertigo235

    vertigo235 Reformed Router Member

    I created guest wifi and vlan 192.168.2.x, so that they are isolated from my private network.

    However, you can still access the admin UI by visiting 192.168.2.1

    Yes there is a password, but I would like to restrict access to this, how can I do that?
     
  2. Elfew

    Elfew Addicted to LI Member

    I think it is not possible easily... I need this option too
     
  3. philess

    philess Networkin' Nut Member

  4. Elfew

    Elfew Addicted to LI Member

    Ok, but it is complicated... Every IP adreess add manually to the script... What about automatic redtriction - maybe allow acces to GUI only for br0 or something like that?
     
  5. lefty

    lefty Networkin' Nut Member

    Just use this, add it to your firewall, it'll block access to the software running on the router (yes this means the webgui):

    iptables -I INPUT -i br1 -m state --state NEW -j DROP
     
    Elfew likes this.
  6. philess

    philess Networkin' Nut Member

    The following two lines (repeated for every port that should be blocked) do work for me:

    Code:
    iptables -I INPUT -i br1 -p tcp --dport 80 -d 192.168.200.1 -j REJECT --reject-with tcp-reset
    iptables -I FORWARD -i br1 -p tcp --dport 80 -d 192.168.200.1 -j REJECT --reject-with tcp-reset
    Where br1 is the name of your guest-vlan-bridge and 192.168.200.1 is the ip of the router he has in that network.
    Repeat for each port, eg. 80 and 443 for HTTP and HTTPS access (if enabled), and 22 for SSH and so on.
     
  7. kthaddock

    kthaddock Network Guru Member

    I think this solution should work, to minimize amount of rules.
    Code:
    iptables -A INPUT -i br1 -p tcp -m multiport --dport 80,443,22 -d 192.168.200.1 -j REJECT --reject-with tcp-reset
    iptables -A FORWARD -i br1 -p tcp -m multiport --dport 80,443,22 -d 192.168.200.1 -j REJECT --reject-with tcp-reset
     
    Elfew and philess like this.
  8. philess

    philess Networkin' Nut Member

    Thank you kthaddock! Dont know much about iptables, obviously :)
     
  9. Elfew

    Elfew Addicted to LI Member

    Thank you guys... Leftys solution is working fine
     
  10. gfunkdave

    gfunkdave LI Guru Member

    You also need to block access to the router on its other LAN IP. Both IPs are available to both VLANs.

    I like to block all ports and only let through specific whitelisted services, just to be a little extra paranoid:

    Code:
    iptables -I INPUT 7 -p udp -m multiport --dports 53,67 -j ACCEPT # allow DHCP and DNS service
    iptables -I INPUT 8 -i br1 -d 192.168.2.1 -j DROP
    iptables -I INPUT 9 -i br1 -d 192.168.1.1 -j DROP
    
    I insert the rules at positions 7-9 because just inserting them puts them so late in the chain that other rules take precedence and allow the connection.
     
    philess likes this.
  11. lefty

    lefty Networkin' Nut Member

    How are both IP/subnets available to the 'vlans' ? as you call it, which isn't what it is, but we'll call it that just for your sake. When creating the multiple wireless lan, which is what this is, you create say br1, and then assign that virtual wireless network a subnet, by doing so, you assign it the subnet in which only it can use, there isn't a static route created between the subnets, so the rule i posted will work fine, and is far less complex, which is a good thing.

    And if you mean well people using the 192.168.2.1 subnet can still access stuff on the 192.168.1.1, yes they could, but my rule isn't for that, the topic is "Restrict Access to webgui on guest wifi" which is what my rule does, and only does, as far as restricting subnet access between each of the co-existing subnet's is concerned, thats a totally different rule..
     
    philess likes this.
  12. philess

    philess Networkin' Nut Member

    I know what "vlan" is not the 100% correct term for that, but i am sure everyone knows what i mean by it...
    Yes i know that your rule only applies to services on the router itself and has nothing to do with routing between the two subnets.

    But honestly, i havent tried your rule yet (will do later today) because it "looks weird" to me haha.
    How does the rule specify which router services are blocked? eg. ports etc. I have to look up about the -m state option i guess.
    Right now the multiport version works fine for me, but i will try yours too.
     
  13. lefty

    lefty Networkin' Nut Member

    @ philess - i wasn't necessarily talking to you, my last response was to gfunkdave, since this user is the one that says both subnets will be available to the guest wifi, which i still don't understand...

    The choice to use the rule i posted is up to you, if you have some other working rule and use it, by all means use it of course. The rule i posted does only what the topic of this thread requested, blocks webgui access on guest wifi.
     
    philess likes this.
  14. Bird333

    Bird333 Network Guru Member

    Access to both subnets shouldn't be possible unless 'lan access' is active
     
  15. gfunkdave

    gfunkdave LI Guru Member

    If you are using Tomato to create multiple wireless networks on different LAN segments, each LAN segment is properly referred to as a VLAN.

    You're correct. We are not creating a static route between VLANs. But Tomato will still allow cross-VLAN connectivity to the router itself, even without an appropriate rule. I suspect it's because the router's IP addresses in both VLANs are somehow bridged together. I don't know. But, if you don't believe that it's possible...try to access the router's IP in VLAN 1 while connected to the wireless from VLAN 2, and vice versa. This is how 1.28.7500 MIPSR2Toastman-VLAN-RT K26 USB VPN works, at any rate.

    This is why both rules I posted are necessary - to kill incoming connections to both VLAN IP addresses on the router when coming from the guest VLAN.

    I didn't say both subnets are available to the guest wifi. I said that the router itself can be accessed from either VLAN (or subnet, if you prefer) by trying to connect to either of its IP addresses.

    Remember, the question was how to block access to the router from the guest VLAN. I am saying that you need to block incoming connections to both of the router's IP addresses from the guest VLAN. If you just block access to 192.168.2.1, people on the guest VLAN will still be able to connect to the router on 192.168.1.1 unless you add the correct filter from my previous post.
     
  16. philess

    philess Networkin' Nut Member

    I can confirm that using 1.28.9013 MIPSR2R1.1f-RAF K26 USB VLAN-VPN-NOCAT-LIGHTY it is the same behavior.
    Connecting to both router IP´s from inside guest-wifi works, unless both are blocked as above.
     
  17. gfunkdave

    gfunkdave LI Guru Member

    @philess - as for your other question about my iptables rules...the first rule explicitly allows DHCP and DNS service (udp connections on ports 53 and 67). The next two rules disallow all other connections.
     
  18. GhaladReam

    GhaladReam Network Guru Member

    lefty's solution blocks both router IP's when connected to my guest wifi. Thanks lefty!
     
  19. lefty

    lefty Networkin' Nut Member

    You are welcome.

    @ gfunkdave: this is what you said, read it closer..

    For the record, this is not vlans, you are not creating a virtual interface, then bridging that to a physical lan port on another subnet. This topic is how to block guest wifi from accessing the router's webgui, nothing more. When you create br1 and assign it to say 192.168.2.1, then make that the guest wifi, that is the only subnet that will be available to the guest wifi is 192.168.2.1 - these users can still access software running on the router (yes including webgui) @ 192.168.1.1 - with the rule i posted, it blocks br1 - which is the guest wifi - from accessing any software running on the router. To block br1 from being to access br0's subnet, another simple rule would apply:

    Code:
    iptables -I FORWARD -i br1 -o br0 -m state --state NEW -j DROP
    and to block br0 from being able to access br1's subnet, which most times need not apply:

    Code:
    iptables -I FORWARD -i br0 -o br1 -m state --state NEW -j DROP
    To me, the rule you posted blocks a subnet that isn't even available to br1 (192.168.1.1) only software is available to it on that subnet. But to each their own on how to restrict access, as i said, if you have a rule that works for you, by all means use it.
     
  20. gfunkdave

    gfunkdave LI Guru Member

    Ah, I didn't see your initial post. Yes, your method works too and in only one line instead of two. :)

    Are you certain that your method will allow devices connected to br1 to still get DHCP and DNS service from the router? It seems that your method still needs to explicitly allow UDP on ports 53 and 67 to permit DHCP and DNS, otherwise it will reject those connections.

    As for terminology, color me confused. Wikipedia says:

    This seems to be exactly what we're doing here - so I don't understand the distinction you're making. These are even called VLAN builds of Tomato, so I don't understand why you're saying these are not VLANs. The guest wifi is on a separate LAN bridge shared with another on the same physical router: in other words, a VLAN. Please explain what I'm missing.
     
  21. philess

    philess Networkin' Nut Member

    I *think* what he means is that there is a difference between what we do ("Virtual LAN") and the actual 802.11Q VLAN standard.
     
  22. lefty

    lefty Networkin' Nut Member

    A wireless LAN created on a virtual wireless interface is not a VLAN, not by definition at all, you guys using this terminology within this forum can really throw people that do know the difference very far off. You do not know what you are talking about when you keep saying VLAN. VLAN is either port based group switching, where you take a physical LAN port on the router and assign that a whole different subnet - then you may or may not bridge a wireless interface to it - doesn't matter if you do or you don't. Which is what the VLAN part of the tomato builds refer to - either being able to have port based group switching functionality or not. They have nothing to do with multiple wireless lans, you don't need a 'special' build to do multiple wireless lans, you could do that on either the non VLAN or VLAN featured tomato builds. By example, i could have the router's physical port 1 on a 192.168.1.1/255.255.255.0 subnet and have the physical port 2 on 172.16.0.1/255.255.255.0 subnet, create a trunk to each of these subnet's so they can communicate with each other, and create trunks to the WAN port so both subnets could have internet functionality and restrict accordingly - and note, this has nothing to do with wireless, no wireless anything was involved in this procedure.

    Or it means 802.11q tagging/trunking - which is the more standard definition - somewhat of what i explained above, but i'm trying to keep it as simple as possible because you don't understand the topical concepts yet. Multiple wireless LANs really have nothing to do with either, they are just that, multiple wireless lans. Since you went to wikipedia to look at definition you should read the article more closely, i'm fairly sure you won't find any wireless references in it and it'll mainly be about physical LAN switches with manage capability. VLANs are something that existed before the wireless networking medium did.

    As far as the rule i posted goes, yes i am sure it'll still let DHCP or DNS thru, why not try it and see for yourself. It only blocks the router's software, such as the webgui, or if you had optware - the guest network would be restricted from it unless you allow it. It doesn't block internet services such as DNS nor is there any reference in the rule itself to block such an internet protocol.
     
  23. Monk E. Boy

    Monk E. Boy Network Guru Member

    Tomato is capable of 802.11q tagging & untagging with VLAN builds, though I don't think it can be performed through the GUI. The reason they're called VLAN builds is because they support VLANs, not just multiple wireless networks. You can have each ethernet port be on a separate VLAN and combine ports (via 802.11q tagging). Wireless expands upon this VLAN tagging functionality since inside the SoC each wireless network is considered a virtual port.
     
    philess and koitsu like this.
  24. gfunkdave

    gfunkdave LI Guru Member

    You're right.

    This is exactly what Tomato is doing with virtual wireless networks. We create separate bridges (br0, br1, etc) on different subnets and assign any combination of LAN ethernet ports and virtual wireless adapters to these bridges.

    I really think you and I are agreed on the meaning of VLAN; we're just going about opposite ways of describing it.

    802.11q tagging does not a VLAN make. Rather, 802.11q is a way to segregate trunked VLAN traffic. Again, I don't think anyone (certainly not me) has said that virtual wireless interfaces constitutes a VLAN all by themselves. Read our/my posts more carefully yourself. Virtual wireless interfaces are means to access VLANs defined in Tomato, nothing more. We are agreed on this.

    Allow me to educate you. With DNSMasq serving DHCP and DNS to the LAN, this means that clients MUST be able to send UDP datagrams to the router (the iptables INPUT chain) on ports 53 (DNS) and 67 (DHCP). Your client rule kills ALL inbound connections to the router - not only attempts to connect to the router's http, ssh, and telnet interfaces, but also its DHCP and DNS daemons. Also, if you had any shared printers or disk drives plugged into the router's USB ports, you would not be able to access them. If you are not using the router as DHCP or local DNS repeater, then you don't need to worry about this. But most people do use their router for these functions.

    The solution, as I've outlined above, is to either blacklist certain ports (as someone posted, blacklisting ports 80, 443, 22, and 23) or choose which ports to whitelist (my approach).

    I suspected I was correct and actually tried it out. Sure enough, apparently I understand how iptables works (at least in this case :)) :

    Code:
    david@meadows-guest:~$ telnet 192.168.3.1 80
    Trying 192.168.3.1...
    ^C
    david@meadows-guest:~$ nslookup cnn.com
    ;; connection timed out; no servers could be reached
    

    You can do it in the GUI, at least in Toastman builds. On the Advanced -> VLAN screen, there is a column headed "VID". That's actually the 802.11q tag. You can change it by expanding the VID Offset and typing in an offset to be added to the defaults. Not sure how well this works; I've never needed to use it.
     
    philess likes this.
  25. lefty

    lefty Networkin' Nut Member

    No i don't agree with your definition of VLAN, its not whats taught in any network class - and i been doing it for around 17 years - you just can't seem to separate yourself from the aspect that VLANs have been around WAY longer than WIRELESS, and that it has nothing to do with wireless anything - unless 802.11 refined the definition - which i surely doubt is so. And for the record, a LAN has to have functionality beyond a wireless medium, IE i can't wire plug my computer into your WIRELESS LAN - thus not a TRUE FULLY FUNCTIONAL LAN! Also i'm not going to allow you to educate me on DNSmasq or DHCP, the rule i posted blocks SOFTWARE running on the router, NOT services ports, it blocks SOFTWARE running on the router at the interface level, not filtering ANY ip's/ports etc. Care to show me anywhere in the rule i posted that blocks any kinds of ports or IPs? No, its not there because it doesn't block that! You going into some shell and doing an NSlookup proves NOTHING! SOFTWARE IS BLOCKED FROM THE GUEST NETWORK, NOT THE PORTS OR PROTOCOLS THEMSELVES! And i suspect there is something else conflicting in your rules, YOU SHOULD NOT HAVE BEEN ABLE TO EVEN TELNET OR SSH to the unit under the guest network! The rule blocks guest network from having any access to SOFTWARE RUNNING ON THE ROUTER! You are going on about printers etc - most of which have NOTHING to do with a guest wireless network - most people set guest networks up for VERY limited access - mainly internet, and if your are going to allow the GUEST to use more than limited access - what would be the point of the guest network to begin with? Why not just let them use your LAN for the extra services? The rule has already been tested by forum users within this thread and confirmed working, i'm fairly sure they would have reported differently if it didn't. Thats all i need to know. :)

    No i suggest you go back to the drawing board on studying IPTABLES and how they work and what they do, as i said, the rules you posted are doing things that they shouldn't and don't need to do...
     
  26. Malitiacurt

    Malitiacurt Networkin' Nut Member

    Code:
    iptables -I INPUT -i br1 -m state --state NEW -j DROP
    Lefty's solution doesn't work. Using my test laptop I could no longer connect to the guest network on br1. I even tried with only this rule in the iptables. (With guest network on br1 and main network on br0)

    If I have more time later this week without disrupting others I'll try again but I think I can connect to the guest network with a static IP instead of using DHCP, with Lefty's rule enabled. This won't work for this situation but I'm curious how Elfew tested his successfully.

    Code:
    iptables -A INPUT -i br1 -p tcp -m multiport --dport 80,443,22 -d 192.168.2.1 -j REJECT --reject-with tcp-reset
    iptables -A FORWARD -i br1 -p tcp -m multiport --dport 80,443,22 -d 192.168.2.1 -j REJECT --reject-with tcp-reset
    Kthaddock's suggestion does not work either. 4 lines total, for 2 different ips 5.1 and 2.1 but I could still access webgui from guest network.
     
  27. gfunkdave

    gfunkdave LI Guru Member


    Believe whatever you like; I've said what needed to be said and I don't feed trolls. I suspect part of the problem is that English doesn't appear to be your first language, so perhaps there's some misunderstanding. In any case, I'm done. Onto my ignore list you go.

    OP: You have all the info you need to solve the problem now.


    Yup.

    Try the solution I posted upthread...Post 10 I think.

    See ya later, all.
     
  28. GhaladReam

    GhaladReam Network Guru Member

    You must be doing something wrong. Works 100% perfect for me.
     
  29. darkknight93

    darkknight93 Networkin' Nut Member

    try to enter a newline in your Scripts->Firewall, save your Settings, wait 2 minutes, reboot your router - just to make sure the Settings are successfully committed
     
  30. Monk E. Boy

    Monk E. Boy Network Guru Member

    Which is exactly the point. DNSMasq is software running on the router.
     
  31. Malitiacurt

    Malitiacurt Networkin' Nut Member

    You must have done something wrong then or didn't bother restarting your router. I further tested with Lefty's rule and you can only connect using static IP, and DNS resolving does not work.

    Code:
    iptables -I INPUT 7 -p udp -m multiport --dports 53,67 -j ACCEPT # allow DHCP and DNS service
    iptables -I INPUT 8 -i br1 -d 192.168.2.1 -j DROP
    iptables -I INPUT 9 -i br1 -d 192.168.1.1 -j DROP
    This worked fine.
     
  32. lefty

    lefty Networkin' Nut Member

    Not exactly, DNSMasq is a services daemon, it doesn't block the service itself, just blocks br1's access to the software - IE the 'guest' wouldn't be able to modify the config - no access - which is what we want here, not the functionality that the software provides, if it blocked everything services wise, you wouldn't be able to get access whatsoever and these people reporting the rule working would be reporting otherwise.

    There is nothing in the rule that specifies any blocking of anything services wise, nor can anyone show me any different. Probably why its messing people here up, its such a simple rule, but what most people learn in the long run with networking is keep it as simple as you can, the more complex you make the rules, and especially rules that are not needed, the more chances you have of something messing up. Oh and to those that keep saying it doesn't work, guess what, the rule gfunkdave posted doesn't work either.

    @ gfunkdave - For the record, i already stated that if you have a rule that works for you, use it, but you couldn't seem content with that and wanted to argue a pointless point, so you speak of trolls, i only see one here. So yes, please add me to your ignore list. I shall do the same for you as well. :)
     
  33. Monk E. Boy

    Monk E. Boy Network Guru Member

    And the built in web server isn't a services daemon? :(
     
  34. koitsu

    koitsu Network Guru Member

    :D

    Code:
    root@gw:/tmp/home/root# ps | grep httpd
      915 root      1372 S    httpd
    root@gw:/tmp/home/root# service httpd stop
    .
    Done.
    root@gw:/tmp/home/root# service httpd start
    .
    Done.
    root@gw:/tmp/home/root# ps | grep httpd
     4074 root      1372 S    httpd
    
     
    philess likes this.
  35. lefty

    lefty Networkin' Nut Member

    Sure it is, as i said, it blocks br1's (guest network in this case) config access to the software - afaik the built in web server isn't providing br1 with any services here - unless the built in web server is starting to provide services such as DNSMasq - which i don't think is the case. I believe tomato's built in web server provides itself (and you - br0 - which we don't block here) with access for the router config, i don't think it provides services such as DNSMasq. You can however set DNSMasq options within the web gui, but as far as providing the actual dnsmasq daemon, the httpd doesn't do that.

    @ koitsu : no thanks, i like mine better ;)

    Code:
    root@openwrt-nbd:~# ps | grep httpd
     2742 root      1344 S    httpd -c cgi-bin/**|**.sh|**.cgi|**.csv -d /
     6124 root      1372 S    grep httpd
    root@openwrt-nbd:~# service httpd stop
    -ash: service: not found
    root@openwrt-nbd:~# service httpd start
    -ash: service: not found
     
  36. koitsu

    koitsu Network Guru Member

    You're running some custom environment, such as Entware or Optware with a modified shell and with a $PATH that probably lacks /sbin. All support requests can essentially be /dev/null'd unless the user is using the stock firmware environment, I'm sorry to say.

    Code:
    root@gw:/tmp/home/root# echo $PATH
    /opt/usr/sbin:/opt/sbin:/opt/bin:/usr/local/sbin:/usr/sbin:/usr/bin:/sbin:/bin
    root@gw:/tmp/home/root# which service
    /sbin/service
    root@gw:/tmp/home/root# ls -l /sbin/service
    lrwxrwxrwx    1 root    root            2 Mar 27 05:13 /sbin/service -> rc
    root@gw:/tmp/home/root# service
    Usage: service <service> <action>
    root@gw:/tmp/home/root# echo $SHELL
    /bin/sh
    root@gw:/tmp/home/root# ls -l /bin/sh
    lrwxrwxrwx    1 root     root             7 Mar 27 05:13 /bin/sh -> busybox
    
    Firmware I'm using is tomato-K26USB-1.28.0502.1MIPSR2Toastman-RT-N-Ext.trx.
     
  37. jerrm

    jerrm Network Guru Member

    Folks are talking past each other. Whatever executable is providing the service is irrelevant.

    The single line
    Code:
    iptables -I INPUT -i br1 -m state --state NEW -j DROP
    is fine, but blocks all traffic from br1 destined for the router including dhcp and dns traffic.

    If the router is providing dns/dhcp then you need at least:
    Code:
    iptables -I INPUT -i br1 -m state --state NEW -j DROP
    iptables -I INPUT -i br1 -p udp -m multiport --dports 53,67 -j ACCEPT
     
    tommyv, BikeHelmet and Monk E. Boy like this.
  38. Bird333

    Bird333 Network Guru Member

    This doesn't work (at least for me). And I don't see how it could. Keep in mind I am not an expert, but this blocks all new connections. Computers connect to other computers by ports. That command blocks all port connections coming from 'br1'. Therefore I don't know how the router could hand out ip addresses if it is dropping all attempts coming from 'br1'. Maybe clients on 'br1' have a local cache of ip addresses that's why it works for some. Maybe the order of the iptables rule is not correct. I don't know but it doesn't work for me and I don't see how it could work.
     
  39. gfunkdave

    gfunkdave LI Guru Member

    I feel vindicated. :)
     
  40. Monk E. Boy

    Monk E. Boy Network Guru Member

    To be fair, I wasn't really talking past him, I was trying to lead him back from the precipice he had walked out on.
     
  41. GhaladReam

    GhaladReam Network Guru Member

    I apologize, you are correct. I didn't restart my router, I just put lefty's software-blocking command in, which seemed to work, until I restarted, at which point no one on br1 could get an IP (due to blocking of all software).
     
  42. GhaladReam

    GhaladReam Network Guru Member

    Code:
    iptables -I INPUT -i br1 -m state --state NEW -j DROP
    iptables -I INPUT -i br1 -p udp -m multiport --dports 53,67 -j ACCEPT
    This is working the best for me. Blocks all router software on br1 except for DNS and DHCP.
     
    mauzzz likes this.
  43. philess

    philess Networkin' Nut Member

    I think this can only actually work if the order in the iptables rules is correct. I cant help but feel odd about using this approach to the "problem". But if it works, use it! :)
     
  44. jerrm

    jerrm Network Guru Member

    But that is true when adding any iptables rules.
    I'm not sure what's odd about it. There are only two basic iptables approaches to take - block everything and allow specific requests, or allow everything and block specific requests. You can nitpick over optimizaton, whether the default br1 ACCEPT rule should be deleted, whether these lines should be inserted later in the chain, etc. For general "place these two lines in your gui firewall script and it should work across most tomato configs," I don't see anything worrisome.
     
    philess likes this.
  45. philess

    philess Networkin' Nut Member

    Absolutely, i agree. As i said, its just a odd feeling about that rule. Dont know how else to put it.
    Also, the OP was specific about blocking the web GUI, and not "block everything but xy".
    So i suppose the other approach (ports 80,443 drop using multiports, everything else untouched)
    seems more appropriate to this topic specifically.
     
  46. jerrm

    jerrm Network Guru Member

    I can see that. Even though the original "block all" rule listed here didn't originate from me, I do generally default to the "block everything" stance, so it seems rather routine to me.
     
    philess likes this.
  47. gfunkdave

    gfunkdave LI Guru Member

    Since I think that the "block everything" approach originated with me in this thread, I'm curious why it works in that order. It shouldn't. I remember specifically having to add the rules to the chain by specifying their order. Also, I had to insert them later in the chain (starting around position 7 or so) because otherwise, other rules appeared earlier and overrode them.
     
  48. jerrm

    jerrm Network Guru Member

    Code:
    iptables -I INPUT -i br1 -m state --state NEW -j DROP
    iptables -I INPUT -i br1 -p udp -m multiport --dports 53,67 -j ACCEPT
    Insert without a line number always puts the rule at position 1 in the chain. In the above code block, the second insert command takes the #1 spot and pushes the preceding "block all" rule to position #2.

    Maybe when you were first testing you were using append instead of insert?
     
  49. gfunkdave

    gfunkdave LI Guru Member

    Hmm...no, I am pretty sure I was using insert. I just remember the rules appearing after other rules, generated by Tomato, that allowed the connection. In any case, it works. :)
     
  50. GhaladReam

    GhaladReam Network Guru Member

    Putting those 2 lines in my firewall up script and rebooting the router results in a working solution for me. Guests can no longer access the WebUI (or any other service on the router) other than DNS and DHCP, which is all I want them to be able to use anyway.
     
  51. Magdiel1975

    Magdiel1975 Networkin' Nut Member

    I tried jerrm
    iptables -I INPUT -i br1 -m state --state NEW -j DROP
    iptables -I INPUT -i br1 -p udp -m multiport --dports 53,67 -j ACCEPT

    and worked like a charm..
    Thanks jerrm.
     
    Last edited: Apr 21, 2015

Share This Page