I'm trying to harden a server with iptables without accidentally locking myself out of remote access. Instead of using a default DROP policy, I inserted these rules near the top of the INPUT chain to block several TCP and UDP destination-port ranges:
`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 successfully prevent outside clients from connecting to services on those ports. However, after adding them, commands run locally on the server—such as `curl` or `ping` to external systems—appear to hang until interrupted. Removing the rules, or moving them below my other rules, restores outbound connectivity. I'm not blocking ports 53, 80, or 443, so why are these INPUT rules affecting connections initiated by the server?
3 Answers
A more conventional setup is to deny unsolicited inbound traffic by default and explicitly allow the services you intend to expose. For example, allow loopback, established and related traffic, SSH with care, and the required DNS, HTTP, or HTTPS services, then use a final DROP or REJECT rule. Make sure you have a tested rollback method before changing a remote firewall, because an incorrect rule can lock you out.
The most likely cause is that your rules are being applied to reply packets for outbound connections. A firewall needs a stateful rule near the top of INPUT, before these DROP rules, such as `-m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT`. When the server starts an outbound connection, the response comes back through INPUT. If the connection’s source port happens to fall inside one of the blocked ranges, the reply can be dropped unless the established-connection rule accepts it first. Rule order matters because `-I` inserts rules at the top.
These rules only match packets entering the INPUT chain, but that includes return traffic for connections initiated locally. They match destination ports as seen on the incoming packet, which are often the client’s temporary source ports—not necessarily the remote service port 53, 80, or 443. That is why blocking a range of ports based on what attackers supposedly prefer is not a reliable security strategy.
That can happen if the system’s ephemeral source-port range overlaps 2000–3000 or 4000–5000. Check it with `sysctl net.ipv4.ip_local_port_range`. Also review the complete ruleset with `iptables -L -n -v --line-numbers`, since the exact behavior depends on the other rules.