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.


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?

6 Answers 6


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


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.

  • 5
    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. Commented Dec 22, 2013 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
    Commented Dec 22, 2013 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? Commented Dec 22, 2013 at 20:05
  • 5
    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). Commented Dec 22, 2013 at 21:06
  • 1
    in iptables v1.8.4 you need to run the command as sudo, otherwise you will receiv the above mentioned error Commented Jun 22, 2022 at 9:31

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  --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 --dport 80 -j REDIRECT --to-ports 8080
# OK
  • 9
    Wow this is a really bad error message... Thanks!
    – fabiomaia
    Commented Jul 29, 2021 at 12:06
  • 1
    incredible, instead of error, the output must say 'run as root' :D Commented Mar 7 at 12:08

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

-p tcp
  • Additionally, it must specify a protocol that has the concept of ports, as @FalconMomot pointed out in a comment earlier.
    – user
    Commented Dec 30, 2013 at 12:54
  • You are right, for that detail :) Commented Dec 30, 2013 at 20:18
  • 2
    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" ` Commented Jul 23, 2021 at 0:09

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.

  • 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? Commented Mar 12, 2021 at 7:27

@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 :)

  • +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
    Commented Dec 30, 2013 at 9: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
    Commented Dec 30, 2013 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
    Commented Dec 30, 2013 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. Commented Jan 6, 2014 at 5:07
  • @CalyoDelphi if you do a search for "netfilter packet flow diagram", you'll see where every table & chain applies ;-)
    – pepoluan
    Commented Jan 6, 2014 at 14:21

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.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .