Fix iptables "Bad Argument: dport" Errors (2026)

The iptables service is failing to start because one or more rules in your current configuration are malformed, specifically with an invalid dport (destination port) value. This usually means a port number is being used where a protocol name or a range is expected, or vice-versa, or a syntax error is present in the port specification.

Here are the common culprits and how to fix them:

1. Protocol Mismatch with Port Specification

This is the most frequent cause. You’ve specified a port number for a protocol that doesn’t use port numbers in the same way, or you’ve forgotten to specify the protocol altogether. iptables often defaults to TCP if no protocol is given, but this isn’t always safe or intended.

Diagnosis:
```
sudo iptables-save | grep 'dpt:'
```
Look for lines where dpt: is used without a preceding -p tcp or -p udp (or other relevant protocol). For example, iptables-save might show ... -A INPUT -d 192.168.1.100 -m state --state NEW -j ACCEPT and you intended this to be for a specific port, but dpt is missing or misplaced. Or, you might see ... -A FORWARD -p icmp -j ACCEPT which is fine, but if you then tried to add a port to ICMP, it would fail.
Fix: Explicitly define the protocol and ensure the port is valid for that protocol. If you meant TCP port 80:
```
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
```
If you meant UDP port 53:
```
sudo iptables -A INPUT -p udp --dport 53 -j ACCEPT
```
The --dport option requires a protocol to be specified with -p.

2. Incorrect Port Range Syntax

When specifying a range of ports, the syntax must be precise.

Diagnosis: Search your iptables-save output for port ranges. The correct format is start:end.
```
sudo iptables-save | grep 'dpt:.*:'
```
You might see something like ... -A OUTPUT -p tcp --dport 60000-65535 -j ACCEPT. If this is malformed, like 60000--65535 or 60000: 65535 (with a space), it will fail.
Fix: Ensure the range is contiguous and without spaces. To allow TCP ports from 60000 to 65535:
```
sudo iptables -A OUTPUT -p tcp --dport 60000:65535 -j ACCEPT
```
This tells iptables to match any TCP packet where the destination port falls inclusively between 60000 and 65535.

3. Using Protocol Names Instead of Numbers (or vice-versa) in the Wrong Context

While iptables can sometimes resolve well-known service names (like http for port 80), it’s generally safer and more explicit to use port numbers, especially when troubleshooting. The "Bad Argument: dport" error can arise if you try to use a protocol name where a number is strictly expected or if you’re using a protocol that doesn’t have a standard port mapping.

Diagnosis: Check your iptables-save output for entries that use service names for --dport.
```
sudo iptables-save | grep --dport
```
You might see something like ... -A INPUT -p tcp --dport http -j ACCEPT. While this can work if /etc/services is correctly configured, it’s less robust. The error might also occur if you accidentally type a protocol name (like udp or icmp) where a port number should be.
Fix: Always use numerical port values for --dport. To allow traffic to HTTP (port 80):
```
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
```
To allow traffic to DNS (UDP port 53):
```
sudo iptables -A INPUT -p udp --dport 53 -j ACCEPT
```
This ensures iptables is interpreting a numeric port value, which is its primary expectation for --dport.

4. Non-Standard or Invalid Port Numbers

Port numbers must be within the valid range of 0 to 65535. Specifying a port outside this range will cause an error.

Diagnosis: Scan your iptables-save output for any --dport values that are clearly out of the 0-65535 range.
```
sudo iptables-save | grep --dport | awk -F' ' '{print $NF}' | grep -vE '^[0-9]+$|^[0-9]+:[0-9]+$'
```
This command is a bit more complex, but it tries to isolate port specifications and flag anything that isn’t a simple number or a number:number range. You’ll likely have to manually inspect the output of iptables-save if this doesn’t catch it.
Fix: Correct any port numbers that are out of the 0-65535 range. If you accidentally wrote 70000 for a port:
```
sudo iptables -A INPUT -p tcp --dport 7000 -j ACCEPT
```
This ensures the port number is a valid, usable value within the system’s network stack.

5. Typos in --dport Argument

A simple typo in the option itself or its value is surprisingly common.

Diagnosis: Carefully review your iptables-save output for any misspellings related to port specifications.
```
sudo iptables-save
```
Look for things like --dprot instead of --dport, or --dport 8080 (with a trailing space), or --dport 8080- (missing end port).
Fix: Correct any typographical errors. If you wrote --dprot 80:
```
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT
```
This ensures the iptables command correctly parses the destination port specification.

6. Missing iptables-restore Lock File or Permissions Issue

While less common for the "Bad Argument" error specifically, sometimes a corrupted or locked iptables state file can lead to parsing errors during restoration.

Diagnosis: Check the system logs for messages related to iptables-restore or iptables-save. Look for errors about file locking or access.
```
sudo journalctl -u iptables.service -n 50
sudo grep -i "iptables\|restore\|save" /var/log/syslog
```
You might see messages like iptables-restore: trying to restore rules, but lock is held by another process or permission denied errors.

Fix: Ensure the iptables service is stopped before manually editing rules or restoring. Remove any stale lock files if necessary (use with caution).

sudo systemctl stop iptables
# If a lock file exists in /run/lock/ or /var/lock/, remove it:
# sudo rm /run/lock/iptables.lock
# Then manually edit your iptables rules or restore from a known good backup
# sudo iptables-restore < /etc/sysconfig/iptables
sudo systemctl start iptables

This ensures a clean state for iptables to load its rules without interference or corruption.

After applying these fixes, try starting the iptables service again:

sudo systemctl start iptables

If you’ve fixed all the "Bad Argument: dport" issues, the next error you’re likely to encounter is a "Bad Argument: saddr" or a similar error related to another malformed rule, or perhaps a REJECT target instead of ACCEPT that causes connectivity issues you didn’t anticipate.