I'm trying to tighten a server's firewall rules without accidentally locking myself out of remote administration. Instead of using a default DROP policy, I inserted these rules near the top of the INPUT chain to block TCP and UDP destination ports in the ranges 2000–3000 and 4000–5000:
`iptables -I INPUT -m multiport -p tcp --dports 2000:3000,4000:5000 -j DROP`
`iptables -I INPUT -m multiport -p udp --dports 2000:3000,4000:5000 -j DROP`
The rules appear to block incoming connections as intended. However, after adding them, commands run directly on the server—such as `curl` or `ping` to external systems—hang until interrupted. Removing the rules, or moving them below my other rules, restores outbound connectivity.
I already have the needed service ports open, such as DNS, HTTP, and HTTPS. Why would an INPUT rule for those destination-port ranges affect connections initiated by the server itself? Could the issue be related to connection tracking, ephemeral source ports, or rule ordering?
3 Answers
Blocking ports because they are commonly attacked is not a very reliable firewall strategy. A safer design is usually to default INPUT to DROP and explicitly allow only the services that should be reachable, along with established and related traffic. For example, allow management access, DNS if the machine provides it, and HTTP/HTTPS as needed, then reject or drop everything else.
Before changing a remote firewall, make sure you have a recovery path and test the rules carefully. The full output of `iptables -L -n -v --line-numbers` would be needed to identify the exact rule being hit.
An INPUT rule matches packets arriving at the server, regardless of whether the connection was initiated locally or remotely. When the server makes an outbound connection, the reply packets come back through INPUT. Those replies may have a source port in one of your blocked ranges, so a rule matching only the incoming packet’s destination port can still drop them.
The usual fix is to use stateful rules and accept returning traffic before the blocking rules, for example:
`iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT`
Then apply more specific restrictions to new incoming connections. Also check the complete ruleset and the rule order, since `-I` inserts rules near the beginning of the chain.
Your server’s outgoing connection normally chooses an ephemeral source port. If the reply arrives with that port as its destination, the INPUT chain can match it against your blocked ranges. This is especially likely if the system’s ephemeral port range has been customized to overlap 2000–3000 or 4000–5000.
Check the configured range with:
`sysctl net.ipv4.ip_local_port_range`
Even if the ranges do not overlap, you should still have an `ESTABLISHED,RELATED` accept rule near the top of INPUT so replies to permitted outbound connections are recognized and allowed.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures