40

The command iptables no longer recognizes one of the most commonly used options when defining rules: --dport.

I get this error:

[root@dragonweyr /home/calyodelphi]# iptables -A INPUT --dport 7777 -j ACCEPT_TCP_UDP
iptables v1.4.7: unknown option `--dport'
Try `iptables -h' or 'iptables --help' for more information.

The add rule command above is just an example for enabling Terraria connections.

Here's what I currently have as a barebones iptables configuration (listiptables is aliased to iptables -L -v --line-numbers), and it's obvious that --dport has worked in the past:

root@dragonweyr /home/calyodelphi]# listiptables 
Chain INPUT (policy DROP 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1       39  4368 ACCEPT     all  --  lo     any     anywhere             anywhere            
2      114 10257 ACCEPT     all  --  any    any     anywhere             anywhere            state RELATED,ESTABLISHED 
3        1    64 ACCEPT     tcp  --  eth1   any     anywhere             anywhere            tcp dpt:EtherNet/IP-1 
4       72 11610 ACCEPT     all  --  eth1   any     anywhere             anywhere            

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 91 packets, 10045 bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain ACCEPT_TCP_UDP (0 references)
num   pkts bytes target     prot opt in     out     source               destination         
1        0     0 ACCEPT     tcp  --  any    any     anywhere             anywhere

I'm also trying to define a custom chain (inspired by this question) to accept tcp & udp connections so that I don't have to define two rules for everything that I want to enable tcp and udp for (such as a Minecraft or Terraria server, or another service entirely). But even this doesn't work:

[root@dragonweyr /home/calyodelphi]# iptables -P ACCEPT_TCP_UDP DROP
iptables: Bad built-in chain name.

This is getting to be very frustrating, in polite terms (the amount of cussing involved with this would make a sailor tell me to watch my mouth). My Google-fu is terrible, so I've yet to find a working solution for any of this. I'm running CentOS 6.5 on the router. Any help and pointers that you guys can offer would be awesome.

EDIT:

Bonus question: I'm also planning to configure port forwarding as well. Is it still necessary to set rules to accept incoming connections over specific ports?

Community
  • 1
Calyo Delphi
  • 511
  • 1
  • 4
  • 6

6 Answers6

44

First give a -p option like -p tcp or -p udp.

Examples:

iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j DROP

iptables -A INPUT -p udp --dport 53 --sport 1024:65535 -j ACCEPT

You could also try -p all but I've never done that and don't find too much support for it in the examples.

dmourati
  • 24,720
  • 2
  • 40
  • 69
  • 3
    I just tried this with `-p all` and I got exactly the same error. `unknown option --dport`. It worked with `-p tcp` but that's not really going to help me in this case since it just leads to the same problem: defining individual tcp/udp rules for everything. – Calyo Delphi Dec 22 '13 at 19:15
  • From my experience, using `all` never worked with specifying a port. However, instead of having multiple rules for different protocols, you can think about the rules in a different direction. Create rules based on the protocol and then use the `multiports` option to group some rules together. – canadmos Dec 22 '13 at 19:23
  • So, if I want to enable Terraria and Minecraft connections, I can use multiports to open 7777 and 25565, and create a TCP and UDP rule for each pair of ports? – Calyo Delphi Dec 22 '13 at 20:05
  • 4
    The option to -p has to be a single protocol that has the concept of ports (`-p ICMP --dport whatever` would not work either, for obvious reasons). – Falcon Momot Dec 22 '13 at 21:06
  • in iptables v1.8.4 you need to run the command as sudo, otherwise you will receiv the above mentioned error – Roman Gherta Jun 22 '22 at 09:31
16

Another possible solution is that you're forgetting to run as root. I just ran into this when using the debian tutorial

$ iptables -t nat -p tcp -I PREROUTING --src 0/0 --dst 127.0.0.1  --dport 80 -j REDIRECT --to-ports 8080
iptables v1.8.2 (nf_tables): unknown option "--dport"
$ sudo iptables -t nat -p tcp -I PREROUTING --src 0/0 --dst 127.0.0.1 --dport 80 -j REDIRECT --to-ports 8080
# OK
Theo Belaire
  • 281
  • 2
  • 6
12

Protocol (-p) is required if you use --dport. Example:

-p tcp
Diego Woitasen
  • 931
  • 5
  • 11
  • Additionally, it must specify a protocol that has the concept of ports, as @FalconMomot pointed out in a comment earlier. – user Dec 30 '13 at 12:54
  • You are right, for that detail :) – Diego Woitasen Dec 30 '13 at 20:18
  • 1
    Personally, I have the error even with `-p tcp`. `$ sudo iptables -A INPUT -p tcp --dport 62668 -j ACCEPT` returns `iptables v1.8.7 (legacy): unknown option "--dport"` ` – Adrien Pavao Jul 23 '21 at 00:09
3

If iptables report that it uses nftables, one needs to use iptables-legacy instead.

For Example:
Use iptables-legacy -A INPUT -p tcp --dport 22 -m state --state NEW -j DROP
Instead of iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j DROP

It's kind of old question, but that's the first in the search results.

weshouman
  • 211
  • 2
  • 4
  • `iptables-legacy` is not available for much longer. So the real question is: Why does it fail with `ipatbles-nft` and how to fix that? – Helmut Grohne Mar 12 '21 at 07:27
3

@dmourati and @diegows already answered your first question, so I'll tackle your second question. And bonus question. And I'll also throw in a bonus tip ;)

iptables -P only accepts BUILT-IN chains. In the filter table, that would be INPUT, OUTPUT, and FORWARD chains.

Port forwarding does not get handled by the INPUT chain, so you don't have to open the port in the INPUT chain. It does get handled by the FORWARD chain, though. Be careful on that.

Bonus tip: When learning and/or troubleshooting iptables, the output of iptables-save is heads & shoulders better than the output of iptables -L -v --line-numbers. Try it, you'll be pleasantly surprised :)

pepoluan
  • 4,918
  • 3
  • 43
  • 71
  • +1 for a good answer, but I'm a little surprised by your last comment. I **hate** diagnosing `iptables` issues from the `-save` output; why do you find it better than `iptables -L -n -v [--line-numbers]`? – MadHatter Dec 30 '13 at 09:44
  • @MadHatter simple example: You can easily see that rules with the `--dport` options actually has `-p tcp` in front. You can also see how/when rule processing jumps from a built-in chain (e.g., INPUT) to a custom chain (e.g., ACCEPT_TCP_UDP). These two important information are _not_ visible in the output of `iptables -L -n`. – pepoluan Dec 30 '13 at 11:34
  • 3
    Another benefit: I can do `iptables-save > somefile`, edit `somefile` using vim, then doing `iptables-apply -t 600 somefile` to test it. If I inadvertently block myself out, after 600 seconds the rules revert. – pepoluan Dec 30 '13 at 11:35
  • The bonus tip is very much appreciated, and already being used. I'd been using `iptables-save` to help myself learn from a raw config dump before I asked this question. I did not expect the `FORWARD` chain to be where I need to pay attention for port forwarding, however. I'll have to read up about that. – Calyo Delphi Jan 06 '14 at 05:07
  • @CalyoDelphi if you do a search for "netfilter packet flow diagram", you'll see where every table & chain applies ;-) – pepoluan Jan 06 '14 at 14:21
0

Maybe an edge case scenario, but I got this error when I had apparently upgraded my kernel and not rebooted yet and some kernel module was not loaded yet. The module could not be loaded because the running kernel was a different version than the installed kernel. Rebooting solved the problem.

cdauth
  • 861
  • 9
  • 18