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

Help Shibby iptable issue

Discussion in 'Tomato Firmware' started by Sean Rhodes, May 6, 2014.

  1. Sean Rhodes

    Sean Rhodes Serious Server Member

    I'm trying to create a rule to block internet access from 9pm to 9am using the time module:
    iptables -A INPUT -m mac --mac-source 34:23:87:5E:71:95 -m time --utc --timestart 01:00 --timestop 13:00 -j DROP
    The problem is I keep getting the following error:
    iptables v1.3.8: Unknown arg `(null)'
    Can anyone see anything wrong with the code, or is anything missing from this compiled version of iptables that isn't interpreting the rule correctly?

    Thanks in advance
  2. koitsu

    koitsu Network Guru Member

    1. iptables/netfilter modules are notorious for this; their parsers are awful and the messages are 80-90% of the time cryptic as hell. It's my #1 or #2 complaint about the firewalling stack on Linux... *sigh* :)

    The problem is with the --utc flag: there is no such flag (there may be in newer versions of the module, but there isn't here). Remove it and you'll get quite a different error ("No chain/target/match by that name"). Google for "iptables time module no chain/target/match" and you'll find lots of others talking about it. The solution for that is to run modprobe ipt_time before doing your iptables command, then it "just works". Not the first time I've seen this...

    You should get in the habit of doing iptables -m {module} -h and looking at the usage syntax mentioned. The usage syntaxes are printed/displayed by the module themselves not iptables (rephrased: the usage syntax for the module is contained within code in the module itself). There is great irony in the fact, though, that you can do iptables -m time -h without doing modprobe ipt_time first and still get a usage syntax. Oh iptables/netfilter... *sigh*

    2. This is not a "Shibby issue"; reproducible on Toastman as well. This is a general iptables/netfilter and module thing.

    3. Matter of opinion, but start/stop times for certain rules should be done within cron, not within iptables itself. For a year or more I've pondered what the implications are of the time module, meaning how it'd functionally work without destroying performance with repeated time/clock lookup calls. Timekeeping "stuff" should really not be done in a netfilter module, especially considering there's no DST handling in it. cru can be used to manage cron entries that do things at certain times.

    4. Don't forget that iptables -A INPUT will append to the end of the chain, which means the rule might not be matched if preceding rules match first. Rule ordering matters greatly.
    James Good likes this.
  3. Sean Rhodes

    Sean Rhodes Serious Server Member

    Thanks for your help Koitsu,

    I will try using cru in the wanup or init page with just the iptable line to drop the mac address and see how that works (based on your comments above, I suppose I should list all the rules and maybe use the -I depending on what rules come before)

    As a quick question, which is better DROP, or REJECT?
  4. koitsu

    koitsu Network Guru Member

    It depends on what you desire.

    DROP will cause the packet to be dropped and nothing sent back to the client whose packet matched the rule -- the client has no idea if this is real packet loss or what's going on, so the IP stack will attempt retries and wait for timeouts and so on.

    REJECT will cause the packet to be dropped and an ICMP destination-unreach message back to the client, allowing the client's IP stack to quickly become aware of the failure.

    In this particular case, because the packets in question are across your LAN, I would strongly suggest using REJECT -- there's no harm in sending back an ICMP destination-unreach to a client who is already on your own network.

    For blocking inbound traffic from the Internet/WAN, I always advocate use of DROP -- you don't want to send back ICMP destination-unreach to someone, as it can give them "general hints" about your firewall setup/configuration, and also keeps DoS attacks (say a TCP SYN attack against a port you have blocked) from keeping your router tied up trying to send back ICMP messages as fast as they can send you TCP SYN. (It won't stop something like a DoS or DDoS attack that's intended to saturate your network connection or your ISPs -- there isn't jack squat you can do about that)

    And if you ever explicitly reject TCP packets (-p tcp -j REJECT in use), be sure to use --reject-with tcp-reset as well.

Share This Page