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

Again access restrictions with Thibor 15c.....

Discussion in 'HyperWRT Firmware' started by Dweezle, Aug 18, 2006.

  1. Dweezle

    Dweezle Network Guru Member

    Ok, maybe i'm stupid.... but access restrictions are not working...
    My WRT54G with Thibor 15c will not accept the access rules, it makes me crazy.

    Here the rules i will use:

    #1 allow 24h for mac xxxxxxxxxxx1
    #2 allow SUN-THU 10AM - 10:30pm for mac xxxxxxxxxxx2 (IP is xxx.xxx.xxx.120)
    #3 allow FRI - SAT 10AM - 11:30pm for mac xxxxxxxxxxx2
    #4 deny 24h for ip xxx.xxx.xxx.2 - xxx.xxx.xxx.254

    Pc with IP xxx.xxx.xxx.122 can connect to the internet but is not allowed by the rules.....

    I reflashed the router 3x with Thibor 15c the following way:

    - clear nvram, restore factory defaults
    - upgrade firmware
    - clear nvram, restore factory defaults
    - did a hardware reset
    - clear nvram, restore factory defaults

    Can anyone tell me were is my error? I've tested the rules only with ip-addresses and only with mac addresses always the same. I made a deny rule for the PC with IP xxx.xxx.xxx.122 nothing is happend.....

    I give up if no one has a tip for me....

    Thanx Werner
     
  2. swinn

    swinn Network Guru Member

    The access restrictions feature does work but I believe it only moves to the second rule if the first is not in effect. Atleast this is what I've noticed. This is a rather silly way to do it.. but that's Linksys for you. Hopefully someone will rework it in one of the third party firmwares.
     
  3. rbngan

    rbngan LI Guru Member

    I use Thibor's 15c firmware on a WRT54G. I use it to close down the public access at 10 pm and it works good.

    I have it set up as follows:
    IP set to xxx.xxx.xxx.120-169 (That is the range of public assigned IP addresses)
    Deny
    Everyday
    from 10 pm to 11:55 pm and the second rule is the same as above but the time is set from12 am to 6 am.

    You did not indicate that you checked "Everyday" for your deny. I don't know if that will make a difference. Also, I don't know if the rules are a hierarchy as Swinn indicated. If so you would want to build you rules to follow a logical pattern to allow or deny the ip/mac address you need.

    When I first set this up, I set up an approve rule for IP xxx.xxx.xxx.101 and all other IP's were automatically denied (it lock me out since I was on IP 102). I changed my thought process to what I want to deny and I was successful. This by default makes anyone not in the deny rule allowed. I did not use MAC address so I do not know if they work or not or if they can be mixed with IP. I only limited the DCHP IP's.

    Try putting your rules in reverse order.
    something like this:
    1. deny every day 24h for ip xxx.xxx.xxx.2 - xxx.xxx.xxx.254
    2 deny every day 11:30pm - 10 AM for mac xxxxxxxxxxx2 (will need two rules for this 11:30-1155 and 12am to 10 am)
    3. deny sun-thur 10:30-11:30 for mac xxxxxxxxxxx2



    Hope this helps.
     
  4. Dweezle

    Dweezle Network Guru Member

    Ok, i forgot rules #1 and #4 are assigned to everyday. Reverse order has the effect that the rule "deny 24h ip 2 - 254 as rule #1" is always true and no one can connect to the internet, so this is not useful. I will test a hierarchy order and hope this will help. Only deny rules is a good tip but blocking services and website blocking by keyword are only in allow rules possible, later when my rules will function i want to use this feature.

    With Thibor 14 my rules were functioning. I waited a long time before i did an upgrade to 15c, when nothing helps i go back to Thibor 14 (never touch a running system......).

    Thanx for your tips!!
     
  5. Whatever

    Whatever Network Guru Member

    I use Thibor 15 c too and have noticed the same problem. It was fine with previous versions of this firmware, but seems to have been messed up again with this version.

    All my rules that I use are independant of each otehr - I slectively block for parental reasons at homne adn the "move to 2nd rule only of first is not in effect doesn;t help me at all.
     
  6. hoever

    hoever Network Guru Member

    I also had problems with access restrictions but i have the following solution. Leave the 1st rule blank and start with the 2 rule. So do nothing with the 1st rule and start with the second. I did this and everything works fine for over a month now. Why i don't know but it works for me.

    My kids only have internet access from 17.00 till 22.00 in the week and from 09.00 till 22.00 in the weekends. The pc's from my wife and myself have internet access 24 hours.

    sorry for my bad English.
     
  7. Dweezle

    Dweezle Network Guru Member

    I will check this solution, thanks for your tip!
    I will reply, if this is the way to use the access restrictions.
     
  8. Dweezle

    Dweezle Network Guru Member

    I checked out the workaround and started with the 2nd rule, but this is not working for me. Now the first rule is a deny rule with the mac-addresses for the pc's, which are not allowed to go to the internet thats the way it works, now they are blocked 24hours....

    This weekend i will check DD-WRT....

    Next weekend Draytek....... ;o)

    If someone has a workaround with firewallscript please tell me.
     
  9. Thibor

    Thibor Super Moderator Staff Member Member

    the rules as i understand them are thus: a 24hour rule is in effect always. the timed rules are executed as cron jobs, ie they start via cron at the specified time and end at the specified time. i'm not sure of rulesets whereby rule 2 will only run if rule 1 is in effect, but i'll double check that. i've not dealt with the access restrictions very much other than to check that timed allow/deny rules actually happen and to see exactly what is occuring. i've never looked into rule priorities either as there didn't seem to be any point in doing so. this behaviour can easily be seen from the command line and could be explained by anybody willing to look at the rules and the firewall data to see what's happening. also, the sourcecode is freely available for download and modification.
     
  10. Thibor

    Thibor Super Moderator Staff Member Member

    1st Scenario:
    rule:
    1: allow 24hr designated MAC
    2: deny by time ip range that MAC is within.
    Result: Internet access is allowed within the time denied via rule 2
    2nd Scenario:
    rule:
    1:deny by time designated MAC
    2: allow 24hrs ip range that MAC is within
    Result: Internet access is denied during time stated in rule 1

    i have just tested those 2 situations and more besides and i'm quite satisfied that they are indeed functioning. priority seems to be high(rule 1) -- low(rule20) as rule 1 will override rule 2, 3, 4, etc.
    i have seen that this works by my own two eyes, using a variety of MAC addresses and/or ip's(range and singular) and i've seen that they work.
     
  11. hoever

    hoever Network Guru Member

    Thibor what you say works even with me but......... for a few days and than it don't work anymore. That's the problem is works for a few days. Now when i start with the second rule and do nothing with the first everything works fine for over 5 weeks now.
     
  12. Thibor

    Thibor Super Moderator Staff Member Member

    then i'll keep these rules active and check them in a week
     
  13. Dweezle

    Dweezle Network Guru Member

    Thibor first you make a very good job and i hope we will see Thibor version 999 in 10 years!

    I've not tested a deny rule with ip-range AND mac-addresses within, cause i don't wont to type in xx mac addresses, but i will test it. I think its my error but what i'm doing wrong?

    Please test this 2 rules:

    #1 allow 24h everyday only 1 mac address within (xx:xx:xx:xx:xx:01)
    #2 deny 24h everyday ip-range 2-254 (only ip-range, nothing else)

    PC1 mac= xx:xx:xx:xx:xx:01 IP=192.168.1.100
    PC2 mac= xx:xx:xx:xx:xx:02 IP=192.168.1.101

    PC2 can go into the internet but isnt allowed by the rules.

    Please tell me what i'm doing wrong.......
     
  14. Thibor

    Thibor Super Moderator Staff Member Member

    i can't explain, paste here the output of "iptables -t filter -nvL" and /tmp/crontab
     
  15. Jonix

    Jonix LI Guru Member

    Similar problem on a WRT54GS v.4

    I just posted a question in the HyperWRT Forum, but I have a similar problem. No access restrictions whatsoever works.
    (http://www.hyperwrt.org/forum/viewtopic.php?id=1940)

    Output from "iptables -t filter -nvL":

    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
    469 42436 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 state NEW
    172 40158 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW
    50 2920 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:520
    0 0 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0 psd weight-threshold: 21 delay-threshold: 300 lo-ports-weight: 3 hi-ports-weight: 1
    0 0 logaccept tcp -- * * 0.0.0.0/0 192.168.1.1 tcp dpt:443
    0 0 logdrop icmp -- * * 0.0.0.0/0 0.0.0.0/0
    0 0 logdrop 2 -- * * 0.0.0.0/0 0.0.0.0/0
    0 0 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0

    Chain FORWARD (policy ACCEPT 2442 packets, 755K bytes)
    pkts bytes target prot opt in out source destination
    0 0 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 tcpmss match 1461:65535 TCPMSS set 1460

    Chain OUTPUT (policy ACCEPT 732 packets, 332K bytes)
    pkts bytes target prot opt in out source destination

    Chain lan2wan (0 references)
    pkts bytes target prot opt in out source destination

    Chain logaccept (1 references)
    pkts bytes target prot opt in out source destination
    0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW LOG flags 7 level 4 prefix `ACCEPT '
    0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

    Chain logdrop (4 references)
    pkts bytes target prot opt in out source destination
    0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW LOG flags 7 level 4 prefix `DROP '
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

    Chain logreject (0 references)
    pkts bytes target prot opt in out source destination
    0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 7 level 4 prefix `WEBDROP '
    0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp reject-with tcp-reset

    Chain trigger_out (0 references)
    pkts bytes target prot opt in out source destination

    Any clues?
     
  16. Thibor

    Thibor Super Moderator Staff Member Member

    Jonix: firstly it's bad form to hijack another's thread, but as you're a noob i'll overlook it this time. secondly, your firewall is inactive. access restrictions are firewall rules and cannot operate if your firewall is turned off.
     
  17. Jonix

    Jonix LI Guru Member

    Sorry, I didn't mean to hijack the thread. I thought it was ok to add my problem
    since I judged it to be related. I apologize, next time I'll start a new topic.

    Anyway, the GUI says the firewall IS on, and I don't know how to tell if it's on or off. Is there anything I can do to bring it up manually?
     
  18. Dweezle

    Dweezle Network Guru Member

    Output IPTABLES:

    # iptables -t filter -nvL

    Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
    79 9096 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    0 0 ACCEPT all -- lo * 0.0.0.0/0 0.0.0.0/0 state NEW
    14 884 ACCEPT all -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW
    0 0 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0 psd weight-threshold: 21 delay-threshold: 300 lo-ports-weight: 3 hi-ports-weight: 1
    0 0 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0 ipp2p v0.8.1_rc1 --ipp2p
    0 0 logdrop icmp -- * * 0.0.0.0/0 0.0.0.0/0
    0 0 logdrop 2 -- * * 0.0.0.0/0 0.0.0.0/0
    2 96 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0

    Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
    pkts bytes target prot opt in out source destination
    0 0 ACCEPT all -- br0 br0 0.0.0.0/0 0.0.0.0/0
    0 0 DROP all -- * * 0.0.0.0/0 0.0.0.0/0 state INVALID
    20 1076 TCPMSS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp flags:0x06/0x02 tcpmss match 1453:65535 TCPMSS set 1452
    0 0 logreject tcp -- br0 ppp+ 0.0.0.0/0 0.0.0.0/0 tcp dpt:80 WEBSTR match content 8
    109 66560 TRIGGER all -- ppp+ br0 0.0.0.0/0 0.0.0.0/0 TRIGGER type:in match:0 relate:0
    129 20343 trigger_out all -- br0 * 0.0.0.0/0 0.0.0.0/0
    0 0 logdrop all -- br0 ppp+ 0.0.0.0/0 0.0.0.0/0 ipp2p v0.8.1_rc1 --ipp2p
    129 20343 lan2wan all -- br0 * 0.0.0.0/0 0.0.0.0/0
    109 66560 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
    0 0 logaccept all -- br0 * 0.0.0.0/0 0.0.0.0/0 state NEW
    0 0 logdrop all -- * * 0.0.0.0/0 0.0.0.0/0

    Chain OUTPUT (policy ACCEPT 94 packets, 15202 bytes)
    pkts bytes target prot opt in out source destination

    Chain advgrp_1 (1 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_10 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_11 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_12 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_13 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_14 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_15 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_16 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_17 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_18 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_19 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_2 (1 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_20 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_3 (1 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_4 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_5 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_6 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_7 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_8 (0 references)
    pkts bytes target prot opt in out source destination

    Chain advgrp_9 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_1 (1 references)
    pkts bytes target prot opt in out source destination
    66 11046 advgrp_1 all -- * * 0.0.0.0/0 0.0.0.0/0 MAC 00:12:3F:67:3E:39
    129 20343 logaccept all -- * * 0.0.0.0/0 0.0.0.0/0
    0 0 logaccept all -- * * 0.0.0.0/0 0.0.0.0/0

    Chain grp_10 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_11 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_12 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_13 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_14 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_15 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_16 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_17 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_18 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_19 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_2 (1 references)
    pkts bytes target prot opt in out source destination
    0 0 advgrp_2 all -- * * 0.0.0.0/0 0.0.0.0/0 MAC 00:40:F4:C3:10:E8
    0 0 logaccept all -- * * 0.0.0.0/0 0.0.0.0/0
    0 0 logaccept all -- * * 0.0.0.0/0 0.0.0.0/0

    Chain grp_20 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_3 (0 references)
    pkts bytes target prot opt in out source destination
    0 0 advgrp_3 all -- * * 0.0.0.0/0 0.0.0.0/0 MAC 00:40:F4:C3:10:E8
    0 0 logaccept all -- * * 0.0.0.0/0 0.0.0.0/0
    0 0 logaccept all -- * * 0.0.0.0/0 0.0.0.0/0

    Chain grp_4 (1 references)
    pkts bytes target prot opt in out source destination
    0 0 logdrop all -- * * 192.168.1.2/31 0.0.0.0/0
    0 0 logdrop all -- * * 192.168.1.4/30 0.0.0.0/0
    0 0 logdrop all -- * * 192.168.1.8/29 0.0.0.0/0
    0 0 logdrop all -- * * 192.168.1.16/28 0.0.0.0/0
    0 0 logdrop all -- * * 192.168.1.32/27 0.0.0.0/0
    0 0 logdrop all -- * * 192.168.1.64/26 0.0.0.0/0
    0 0 logdrop all -- * * 192.168.1.128/26 0.0.0.0/0
    0 0 logdrop all -- * * 192.168.1.192/27 0.0.0.0/0
    0 0 logdrop all -- * * 192.168.1.224/28 0.0.0.0/0
    0 0 logdrop all -- * * 192.168.1.240/29 0.0.0.0/0
    0 0 logdrop all -- * * 192.168.1.248/30 0.0.0.0/0
    0 0 logdrop all -- * * 192.168.1.252/31 0.0.0.0/0
    0 0 logdrop all -- * * 192.168.1.254 0.0.0.0/0

    Chain grp_5 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_6 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_7 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_8 (0 references)
    pkts bytes target prot opt in out source destination

    Chain grp_9 (0 references)
    pkts bytes target prot opt in out source destination

    Chain lan2wan (1 references)
    pkts bytes target prot opt in out source destination
    129 20343 grp_1 all -- * * 0.0.0.0/0 0.0.0.0/0
    0 0 grp_2 all -- * * 0.0.0.0/0 0.0.0.0/0
    0 0 grp_4 all -- * * 0.0.0.0/0 0.0.0.0/0

    Chain logaccept (7 references)
    pkts bytes target prot opt in out source destination
    24 1256 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW LOG flags 7 level 4 prefix `ACCEPT '
    129 20343 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0

    Chain logdrop (20 references)
    pkts bytes target prot opt in out source destination
    2 96 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 state NEW LOG flags 7 level 4 prefix `DROP '
    2 96 DROP all -- * * 0.0.0.0/0 0.0.0.0/0

    Chain logreject (1 references)
    pkts bytes target prot opt in out source destination
    0 0 LOG all -- * * 0.0.0.0/0 0.0.0.0/0 LOG flags 7 level 4 prefix `WEBDROP '
    0 0 REJECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp reject-with tcp-reset

    Chain trigger_out (1 references)
    pkts bytes target prot opt in out source destination


    ---

    OUTPUT tmp/crontab:

    PATH=/sbin:/bin:/usr/sbin:/usr/bin

    00 10 * * 0-4 root filter add 2
    30 22 * * 0-4 root filter del 2
    00 10 * * 5-6 root filter add 3
    30 23 * * 5-6 root filter del 3

    If typed in the rules as descriped in my first posting.

    Here is the outgoing log:
    Outgoing Log Table
    LAN IP Destination URL/IP Service/Port Number Protocol
    accepted 192.168.1.102 xxx.xxx.xxx.xxx www TCP
    accepted 192.168.1.102 xxx.xxx.xxx.xxx www TCP
    accepted 192.168.1.102 xxx.xxx.xxx.xxx www TCP
    accepted 192.168.1.100 xxx.xxx.xxx.xxx ntp UDP

    And you see PC with IP: xxx.xxx.x.102 can go into the internet, PC with IP: xxx.xxx.x.100 is allowed by the first rule (MAC 00:12:3F:67:3E:39).
     
  19. Thibor

    Thibor Super Moderator Staff Member Member

    Chain grp_1 (1 references)
    pkts bytes target prot opt in out source destination
    66 11046 advgrp_1 all -- * * 0.0.0.0/0 0.0.0.0/0 MAC 00:12:3F:67:3E:39
    129 20343 logaccept all -- * * 0.0.0.0/0 0.0.0.0/0

    something in this rule(the most important) has set an allow ALL rule, check it closely. rules 2,3 and 4 are not even being processed as this rule is superceeding all the others
     
  20. Dweezle

    Dweezle Network Guru Member

    ok, i thought when the first rule is limited by mac-address then it's only valid for the pc with this mac (falldown processing). A pc with a mac-address that isnt valid goes to the next rule, if this isnt valid then the next rule and so on. This is why i have a "default-deny" rule as the last rule, which is limited by ip-range.

    I will revise my rules and change them. Thanks !!
     
  21. Thibor

    Thibor Super Moderator Staff Member Member

    i think it's possible that something is screwy here, dweezle: check your pm
     
  22. Thibor

    Thibor Super Moderator Staff Member Member

    Thanks for getting back to me Dweezie, it really helps to keep me motivated to do this having people so willing to help me.
    Rule 1: Allow 24/7 for Mac address(ip 1.121)
    Rule 2: Allow time slot for range of ip's(1.100-1.150)
    Rule 3: Block all range 1.2 - 1.254

    Result: Rule 1 takes precedence and pc listed always has access. Pc 1.125 has access only during period specified in rule 2 and then access is blocked as per rule 3.
    if you see anything wrong with this scenario, just let me know
     
  23. Dweezle

    Dweezle Network Guru Member

    Sorry Thibor but since monday morning i have a big problem with our db-server. First i have to solve this problem, before i can solve the problem with WRT54G in our branch office. When i have solved the problem with the db-server i mail you for further information about the problem with the access rules.

    Thanks!!
     
  24. Vindicator

    Vindicator LI Guru Member

    Hi people,

    i have a WRT54GL v1.1 with Thibor15c (thanks Thibor for the excelent work!)

    however, in a scenario similar to the one Thibor described,

    Rule 1: Allow 24/7 for Mac address(ip 2.121) (with and without URL address's defined)
    Rule 2: Block all range 2.2 - 2.254

    The result i got was that PC's that were not defined in Rule 1 (by MAC address) could access the internet.
    However when i defined some URL Address's in Rule 1, they were blocked when 2.121 tried to access them. The rest of the PC's continued to access the internet with no URL filtering.

    It was like Rule 2 was being ignored, although it was enabled and set to deny access to 192.168.2.0/255.255.255.0.

    Thanks!

    Edit - i checked the output from "iptables -t filter -nvL" and it was just like what Dweezle got.
     

Share This Page