Iptables can be rough to debug sometimes, since the error messages from
iptables itself aren't very user friendly at all times. For this reason, it may
be a good idea to take a look at the most common error messages you can get
from iptables, and why you may have gotten them.
One of the first error messages to look at is the "Unknown arg" error. This may
show up for several reasons. For example, look below.
work3:~# iptables -A INPUT --dport 67 -j ACCEPT
iptables v1.2.9: Unknown arg `--dport'
Try `iptables -h' or 'iptables --help' for more information.
This error is simpler than normal to solve, since we have only used a single
argument. Normally, you may have used a long, long command and get this error
message. The problem in the above scenario is that we have forgotten to use the
--protocol match, and because of that, the --dport match isn't available to us.
Adding the --protocol match would also solve the problem in this match. Make
absolutely certain that you are not missing any special preconditions that are
required to use a specific match.
Another very common error is if you miss a dash (-) somewhere in the command
line, like below. The proper solution is to simply add the dash, and the
command will work.
work3:~# iptables -A INPUT --protocol tcp -dport 67 -j ACCEPT
Bad argument `67'
Try `iptables -h' or 'iptables --help' for more information.
And finally, there is the simple misspelling, which is rather common as well.
This is shown below. The error message, as you will notice, is exactly the same
as when you forget to add another prerequisite match to the rule, so it needs
to be carefully looked into.
work3:~# iptables -A INPUT --protocol tcp --destination-ports 67 -j ACCEPT
iptables v1.2.9: Unknown arg `--destination-ports'
Try `iptables -h' or 'iptables --help' for more information.
There is also one more possible cause for the "Unknown arg" error shown above.
If you can see that the argument is perfectly written, and no possible errors
in the prerequisites, there is a possibility that the target/match/table was
simply not compiled into the kernel. For example, let's say we forgot to
compile the filter table support into the kernel, this would then look
something like this:
work3:~# iptables -A INPUT -j ACCEPT
iptables v1.2.9: can't initialize iptables table `filter': Table does not exist
(do you need to insmod?)
Perhaps iptables or your kernel needs to be upgraded.
Normally, iptables should be able to automatically modprobe a specific module
that isn't already inside the kernel, so this is generally a sign of either not
having done a proper depmod after restarting with the new kernel, or you may
simply have forgotten about the module(s). If the problematic module would be a
match instead, the error message would be a little bit more cryptic and hard to
understand. For example, look at this error message.
work3:~# iptables -A INPUT -m state
--state ESTABLISHED -j ACCEPT
iptables: No chain/target/match by that name
In this case, we forgot to compile the state module, and as you can see the
error message isn't very nice and easy to understand. But it does give you a
hint at what is wrong. Finally, we have the same error again, but this time,
the target is missing. As you understand from looking at the error message, it
get's rather complicated since it is the exact same error message for both
errors (missing match and/or target).
work3:~# iptables -A INPUT -m state
--state ESTABLISHED -j REJECT
iptables: No chain/target/match by that name
The easiest way to see if we have simply forgotten to depmod, or if the module
is actually missing is to look in the directory where the modules should be.
This is the /lib/modules/2.6.4/kernel/net/ipv4/netfilter
directory. All ipt_* files that are written in uppercase letters are targets,
while all the ones with lowercase letters are matches. For example,
ipt_REJECT.ko is a target, while the ipt_state.ko is a match.
 | In 2.4 kernels and older, the file extension for all kernel modules was .o,
which changed to .ko for files in the 2.6 kernels.
|
Another way of getting help from iptables itself is to simply comment out a
whole chain from your script to see if that fixes the problem. This is kind of
a last resort problem solver, that may be very effective if you don't even know
which chain is causing the problem. By removing the whole chain and simply
setting a default policy of ACCEPT, and then testing, if it works better, then
this is the chain that is causing the problems. If it doesn't work better, then
it is another chain, and you can go on to find the problem elsewhere.
