Hi, Gurus I'd like to disable all web access except site www.abcd.com and www.dcba.com. And allow all web sites for MAC address in white list. The access restriction page only allow you to block certain site, or as alternative way DNSMASQ can help this? Thank you in advance, and have a good day.
Completely untested, but I think the following would work (in your firewall script): Code: # Allow these hosts unrestricted access iptables -A wanout -i `nvram get lan_ifname` -m mac --mac-source <allowed MAC #1> -j ACCEPT iptables -A wanout -i `nvram get lan_ifname` -m mac --mac-source <allowed MAC #2> -j ACCEPT # Allow everyone access to these sites iptables -A wanout -i `nvram get lan_ifname` -d www.abcd.com -j ACCEPT iptables -A wanout -i `nvram get lan_ifname` -d www.dcba.com -j ACCEPT # Everything else gets blocked iptables -A wanout -i `nvram get lan_ifname` -j DROP Give that a shot and see if it works for you.
lol SgtPepperKSU， I'd like some guru to help me, not geeks...... Just kidding, will give it a try. Thank you!
For the record, I just added those lines to my firewall script, and it worked like a charm. The MAC addresses listed have unrestricted access, and the other computers are limited to linksysinfo.org and google.com (I'm posted from a limited computer right now :smile.
Hi! I would like to use this restriction too but in chosen period of time. Is there any solution for this?
Well, looks like it is not working. I'm wondering if the fault is caused by DNSMASQ. Since after i type in www.abcd.com, tomato would resolve it to ip address (if white list MAC once access abcd).
I don't understand what the problem is. What is it that isn't working for you? You said everyone should be able to access www.abcd.com, and now your indicating that it's not working when one of them can access it (actually all you've said is that they can resolve it - they should have full access to www.abcd.com). Everyone would be able to resolve any DNS address to an IP address, but would only be able to access the ones allowed by the rules. Right now I have this computer as NOT matching a MAC address in the rules, and the only sites I can get to are the ones I listed. Running nslookup, I can resolve any of them to an IP address, but not contact them. EDIT: Since you keep going back to Dnsmasq, I should also point out that no Dnsmasq-based solution will be what I would consider satisfactory, since you cannot guarantee that the client computer will use the router for DNS at all. The only real way to block a site is to block the traffic to that site (which the script I provided does do).
Hi, SgtPepperKSU Well, MAC not in white list still can access any web sites. Or should I block port 80/8080/8000/443/ for MACs not in white list? And how to? Is there anyway to check how these iptables rules affect packages transmission? Thank you again.
You shouldn't have to do anything else. Can you post the output of Code: service firewall restart #attempt to access web from non-matching MAC here iptables -vL ? This will show the packets traversing the firewall chains. EDIT: Just to double-check - are you rebooting after adding the firewall script (the service firewall restart will accomplish the same thing without actually rebooting)? I took that for granted and didn't explicitly mention it. The firewall script isn't read until the firewall is restarted.
here goes the result Code: Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 DROP 0 -- br0 any anywhere 192.168.1.108 0 0 DROP 0 -- any any anywhere anywhere state INVALID 133 10015 ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED 0 0 ACCEPT 0 -- br0 any anywhere anywhere 1 60 ACCEPT 0 -- lo any anywhere anywhere 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:https 0 0 ACCEPT tcp -- any any anywhere anywhere tcp dpt:1723 0 0 ACCEPT gre -- any any anywhere anywhere Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT 0 -- br0 br0 anywhere anywhere 0 0 DROP 0 -- any any anywhere anywhere state INVALID 0 0 TCPMSS tcp -- any any anywhere anywhere tcp flags:SYN,RST/SYN tcpmss match 1461:65535 TCPMSS set 1460 4 160 ACCEPT 0 -- any any anywhere anywhere state RELATED,ESTABLISHED 2 80 ACCEPT 0 -- br0 any anywhere anywhere 0 0 wanin 0 -- eth1 any anywhere anywhere 0 0 wanout 0 -- any eth1 anywhere anywhere Chain OUTPUT (policy ACCEPT 93 packets, 10030 bytes) pkts bytes target prot opt in out source destination Chain wanin (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT tcp -- any any anywhere 192.168.10.2 tcp dpt:51413 Chain wanout (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT 0 -- br0 any anywhere anywhere MAC 00:22:68:A8:4A:65 0 0 ACCEPT 0 -- br0 any anywhere anywhere MAC 00:19:5B:EE:C5:C5 0 0 ACCEPT 0 -- br0 any anywhere anywhere MAC 00:1B:24:B2:5C:7F 0 0 ACCEPT 0 -- br0 any anywhere anywhere MAC 00:1B:24:AF:77:8A 0 0 ACCEPT 0 -- br0 any anywhere anywhere MAC 00:EE:EE:13:51:08 0 0 ACCEPT 0 -- br0 any anywhere anywhere MAC 00:16:E6:9C:F8:B7 0 0 ACCEPT 0 -- br0 any anywhere anywhere MAC 08:00:1F:B2:5A:2F 0 0 ACCEPT 0 -- br0 any anywhere anywhere MAC 00:21:70:83:D8:B0 0 0 ACCEPT 0 -- br0 any anywhere anywhere MAC 00:19:DB:8B:E6:25 0 0 ACCEPT 0 -- br0 any anywhere anywhere MAC 00:0E:35:E8:57:1A 0 0 ACCEPT 0 -- br0 any anywhere anywhere MAC 00:19:DB:BF:7A:84 0 0 ACCEPT 0 -- br0 any anywhere 61.129.88.131 0 0 ACCEPT 0 -- br0 any anywhere 122.70.138.143 0 0 DROP 0 -- br0 any anywhere anywhere
What version are you using? Your FORWARD chain is very strange. The "ACCEPT 0 -- br0 any anywhere anywhere" line should not be until after "wanout 0 -- any eth1 anywhere anywhere". Your wanout chain is never used for WAN traffic from your LAN. Looking at the source code, this order is hard-coded and hasn't changed since at least 1.21 (the beginning of the code in the git repository), so I'm a bit puzzled why yours is in a different order. In any case, we can fix up your FORWARD chain by adding the following, too: Code: # Fix FORWARD chain order iptables -D FORWARD -i `nvram get lan_ifname` -j ACCEPT iptables -A FORWARD -i `nvram get lan_ifname` -j ACCEPT EDIT: also, what does the output of Code: cat /etc/iptables show? And is there anything else in your firewall script?
Here you go again Code: # cat /etc/iptables *mangle :PREROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A PREROUTING -j CONNMARK --restore-mark -A POSTROUTING -j CONNMARK --save-mark :IPTRAFFIC_I - [0:0] :IPTRAFFIC_O - [0:0] -A FORWARD -j IPTRAFFIC_I -A POSTROUTING -j IPTRAFFIC_O -A IPTRAFFIC_I -i eth1 -p tcp -j ACCOUNT --addr 192.168.10.1/255.255.255.0 --tname tf_tcp_wan1 -A IPTRAFFIC_I -i eth1 -p udp -j ACCOUNT --addr 192.168.10.1/255.255.255.0 --tname tf_udp_wan1 -A IPTRAFFIC_I -i eth1 -p icmp -j ACCOUNT --addr 192.168.10.1/255.255.255.0 --tname tf_icmp_wan1 -A IPTRAFFIC_O -o eth1 -p tcp -j ACCOUNT --addr 192.168.10.1/255.255.255.0 --tname tf_tcp_wan1 -A IPTRAFFIC_O -o eth1 -p udp -j ACCOUNT --addr 192.168.10.1/255.255.255.0 --tname tf_udp_wan1 -A IPTRAFFIC_O -o eth1 -p icmp -j ACCOUNT --addr 192.168.10.1/255.255.255.0 --tname tf_icmp_wan1 COMMIT *nat :PREROUTING ACCEPT [0:0] :POSTROUTING ACCEPT [0:0] :OUTPUT ACCEPT [0:0] -A PREROUTING -i eth1 -d 192.168.10.1/255.255.255.0 -j DROP -A PREROUTING -p icmp -d 192.168.1.108 -j ACCEPT -A PREROUTING -p tcp -m tcp -d 192.168.1.108 --dport 443 -j DROP -A PREROUTING -p tcp -m tcp -d 192.168.1.108 --dport 8080 -j DNAT --to-destination 192.168.1.108:443 -A PREROUTING -p tcp -d 192.168.1.108 --dport 51413 -j DNAT --to-destination 192.168.10.2:51413 -A POSTROUTING -p tcp --dport 51413 -s 192.168.10.1/255.255.255.0 -d 192.168.10.2 -j SNAT --to-source 192.168.10.1 -A POSTROUTING -o eth1 -j MASQUERADE COMMIT *filter :INPUT DROP [0:0] :OUTPUT ACCEPT [0:0] -A INPUT -i br0 -d 192.168.1.108 -j DROP -A INPUT -m state --state INVALID -j DROP -A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT -A INPUT -i br0 -j ACCEPT -A INPUT -i lo -j ACCEPT -A INPUT -p tcp -m tcp --dport 443 -j ACCEPT -A INPUT -p tcp --dport 1723 -j ACCEPT -A INPUT -p 47 -j ACCEPT :FORWARD DROP [0:0] -A FORWARD -i br0 -o br0 -j ACCEPT -A FORWARD -m state --state INVALID -j DROP -A FORWARD -p tcp --tcp-flags SYN,RST SYN -m tcpmss --mss 1461: -j TCPMSS --set-mss 1460 :wanin - [0:0] :wanout - [0:0] -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT -A FORWARD -i br0 -j ACCEPT -A FORWARD -i eth1 -j wanin -A FORWARD -o eth1 -j wanout -A wanin -p tcp -m tcp -d 192.168.10.2 --dport 51413 -j ACCEPT COMMIT
Hi,SgtPepperKSU It would be nice if you can clarify how rules in firewall script affect rules set in web interface. Which priority is high in Access Restriction and Firewall scripts? For example, I disable all internet access except certain MACs in Access Restriction, while allow certain web site by putting your rules in firewall script. Also, will user under br0 interface still can access internet through other protocol like UDP port, 8080 port, 4080 port? I'd like to allow MAC not in white list to use UDP/TCP port 8080/8000/4000/4080 to access outside instant message server. And how to not mess all these rules? Excuse for my bad English, thanks for your kindly help.
Well, the order in those rules is messed up, too. Again, what Tomato version are you using? You shouldn't use Access Restriction along with these firewall rules. Don't have anything to do with any of this in the GUI except in the firewall script. Have you tried it with the last set of rules to fix your FORWARD chain? The rules I originally provided blocks everything but traffic to those sites, but be we can certainly modify things to allow UDP. To only block TCP traffic, just add a "-p tcp" before the "-j DROP" in the last rule. If you want to allow only certain ports, we can do that, too.
Hi, SgtPepperKSU In order to make the MAC not in white list able to access Port 8000/4080/etc..., firstly block every packages then allow certain ports? Or the other order? Script would restric in which order, the last lines are effect or the up lines are? Thank you.
As soon as a rule is matched with a DROP or ACCEPT, no more rules are run. So, the easiest way is to have rules to allow what you want to be allowed, then have a rule that blocks everything (the rule will only be executed if none of the "allow" rules matched). So, if you want to allow everyone unrestricted access to certain destination ports, add the following (substituting protocol and port number as approprate, and repeat as necessary) before the DROP rule: Code: #Allow everyone access to certain destination ports iptables -A wanout -i `nvram get lan_ifname` -p udp --dport 8000 -j ACCEPT Did adding the two FORWARD rules get things working for you? Also, you keep not replying with your Tomato version. I'm very curious what you're using that is making the FORWARD chain out of order like that.
That's one of the reasons that makes me so curious. If that's what he's using, then they may have mixed up the FORWARD chain as some dirty hack to get dual WAN working, and fixing it would have a chance of breaking the dual WAN functionality (though, it shouldn't be terribly hard, in that case, to find a proper way to modify the firewall rules to allow it).
Suppose I should have looked at my own test router:- Code: Chain FORWARD (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 ACCEPT 0 -- br0 br0 0.0.0.0/0 0.0.0.0/0 0 0 DROP 0 -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID 26752 1492K TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 tcpmss match 1361:65535 TCPMSS set 1360 2064K 1665M ACCEPT 0 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 16843 951K ACCEPT 0 -- br0 * 0.0.0.0/0 0.0.0.0/0 0 0 wanin 0 -- vlan1 * 0.0.0.0/0 0.0.0.0/0 0 0 wanout 0 -- * vlan1 0.0.0.0/0 0.0.0.0/0 0 0 upnp 0 -- vlan1 * 0.0.0.0/0 0.0.0.0/0 So yes it is an issue with Code: Tomato v1.23.0286 BusyBox v1.12.3 (2009-05-24 05:00:28 CST) built-in shell (ash) Its broken!
And 1.23.0286 is DualWAN? I wonder why they would have effectively neutered the wanin/wanout chains...
Yes It is now up to version but I see no changes mentioned in the change notes The main iptables routing mod for dualwan is an ASSIGNOUT chain which is used to tag packets for specific WANs, IPTRAFFIC used for per-IP traffic accounting (Victek also has a version working) Code: # iptables -nvL -t mangle Chain PREROUTING (policy ACCEPT 333 packets, 44442 bytes) pkts bytes target prot opt in out source destination 281 22307 ASSIGNOUT 0 -- br0 * 0.0.0.0/0 0.0.0.0/0 Chain INPUT (policy ACCEPT 734K packets, 77M bytes) pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 2094K packets, 1672M bytes) pkts bytes target prot opt in out source destination 92 27834 IPTRAFFIC 0 -- * * 0.0.0.0/0 0.0.0.0/0 Chain OUTPUT (policy ACCEPT 222 packets, 31314 bytes) pkts bytes target prot opt in out source destination Chain POSTROUTING (policy ACCEPT 2919K packets, 1776M bytes) pkts bytes target prot opt in out source destination Chain ASSIGNOUT (1 references) pkts bytes target prot opt in out source destination 275 21945 RETURN 0 -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED 6 362 MARK 0 -- * * 0.0.0.0/0 0.0.0.0/0 MARK-RETURN set 0x100 Chain IPTRAFFIC (1 references) pkts bytes target prot opt in out source destination 41 17507 ACCOUNT tcp -- vlan1 * 0.0.0.0/0 0.0.0.0/0 ACCOUNT addr 192.168.1.0/24 tname tf_tcp_wan1 3 228 ACCOUNT udp -- vlan1 * 0.0.0.0/0 0.0.0.0/0 ACCOUNT addr 192.168.1.0/24 tname tf_udp_wan1 0 0 ACCOUNT icmp -- vlan1 * 0.0.0.0/0 0.0.0.0/0 ACCOUNT addr 192.168.1.0/24 tname tf_icmp_wan1 45 9871 ACCOUNT tcp -- * vlan1 0.0.0.0/0 0.0.0.0/0 ACCOUNT addr 192.168.1.0/24 tname tf_tcp_wan1 3 228 ACCOUNT udp -- * vlan1 0.0.0.0/0 0.0.0.0/0 ACCOUNT addr 192.168.1.0/24 tname tf_udp_wan1 0 0 ACCOUNT icmp -- * vlan1 0.0.0.0/0 0.0.0.0/0 ACCOUNT addr 192.168.1.0/24 tname tf_icmp_wan1 It appears that wanout is just not used in this code.
Almost forgot, your scripts works great. Thanks for your help. And looking foward to your new VPN build, especially IPSEC VPN^_^
That would not work. iptables doesn't see any URLs, just IP addresses. It is just smart enough when you add rules to do a DNS lookup and add rules for all possible IP addresses for the host given. However, that isn't possible with wildcards ('*').
Oh, good! I was starting to wonder if it killed your internet completely :-P No promises on a timeline (or even that it will happen) there. I haven't even started looking into it...
So, is there a way to apply/disable the rules at specific time slots in the day? I manage the network for a small company and they would like to allow only a specific list of sites during the day (while blocking everything else) except during lunch hour where they want to open everything. Access restrictions won't do it because https traffic passes right through. Is there a way to do this?
The iptables extensions that can trigger on time are not compiled into Tomato. So, I'm afraid not. It's a shame, too, because I'd sure think that it'd be a simpler way to implement even the access restrictions that are already in the GUI.
Thank you for the quick reply, SgtPepperKSU. I am new at this so please pardon this seemingly not-so-smart question; are these extensions available so they can be compiled with Tomato in a straight forward manner or do they require a lot of tinkering in the original source code and/or kernel code?
The time module shouldn't be hard to compile in. iptables extensions are added to the iptables source and kernel source by just running Path-O-Matic-ng. I used it to add the ROUTE target to iptables a bit back, and it was pretty easy - once I figured out that the directions are out of date and you need to use the SVN repository (even though it is marked as obsolete), not the CVS (as the directions say) or git (as the repositories page indicates) netfilter repositories. EDIT: Looks like the time module should work fine using the git repository. I guess I just had to use the SVN repository for ROUTE since they're kind of trying to wash their hands of it and didn't move support to the newer git repository.
