Wiki‎ > ‎

IPTables Block IP and IP Range

posted Jul 12, 2016, 7:47 AM by Danny Xu   [ updated Jul 12, 2016, 7:57 AM ]

This is the correct way:

iptables -A INPUT -p tcp --match multiport --dport 1024:3000 -j ACCEPT

As an example. Source here.

iptables -A INPUT -p tcp --dport 1000:2000 will open up inbound traffic to TCP ports 1000 to 2000 inclusive.

-m multiport --dports is only needed if the range you want to open is not continuous, eg -m multiport --dports 80,443, which will open up HTTP and HTTPS only - not the ones in between.

Note that the ordering of rules is important, and it's your job to make sure that any rule you add is in a place where it will be effective.


IPTables portmap rules

Portmap listens on port 111. Add following rules to your iptables:

Drop UPD port 111 packets if they are not from
iptables -A INPUT -p udp -s! --dport 111 -j DROP

Drop TCP port 111 packets if they are not from and localhost (
iptables -A INPUT -p tcp -s! --dport 111 -j DROP
iptables -A INPUT -p tcp -s --dport 111 -j ACCEPT


This is how to block an entire subnet:

# iptables -A INPUT -s -j DROP

This is how to block a range of ip's within a subnet:

# iptables -I INPUT -m iprange --src-range -j DROP


To add multiple sources in a single command I would do this:

iptables -t filter -A INPUT -s,, -j ACCEPT

iptables will automatically translate it into multiple rules.


Set some firewall ports to only accept local network connections?

With the kernel's iptables completely empty (iptables -F), this will do what you ask:

# iptables -A INPUT -p tcp --dport 22 -s -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -s -j ACCEPT
# iptables -A INPUT -p tcp --dport 22 -j DROP

This says that all LAN addresses are allowed to talk to TCP port 22, that localhost gets the same consideration (yes, 127.* not just, and packets from every other address not matching those first two rules get unceremoniously dropped into the bit bucket. You can use REJECT instead of DROP if you want an active rejection (TCP RST) instead of making TCP port 22 a black hole for packets.

If your LAN doesn't use the 192.168.0.* block, you will naturally need to change the IP and mask on the first line to match your LAN's IP scheme.

These commands may not do what you want if your firewall already has some rules configured. (Say iptables -L as root to find out.) What frequently happens is that one of the existing rules grabs the packets you're trying to filter, so that appending new rules has no effect. While you can use -I instead of -A with the iptables command to splice new rules into the middle of a chain instead of appending them, it's usually better to find out how the chains get populated on system boot and modify that process so your new rules always get installed in the correct order.

On RHEL type systems, the easiest way to modify firewall chains when ordering matters is to edit /etc/sysconfig/iptables. The OS's GUI and TUI firewall tools are rather simplistic, so once you start adding more complex rules like this, it's better to go back to good old config files. Beware, once you start doing this, you risk losing your changes if you ever use the OS's firewall tools to modify the configuration, since it may not know how to deal with handcrafted rules like these.

Add something like this to that file:

-A RH-Firewall-1-INPUT -p tcp --dport 22 -s -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport 22 -s -j ACCEPT
-A RH-Firewall-1-INPUT -p tcp --dport 22 -j DROP

Where you add it is the tricky bit. If you find a line in that file talking about --dport 22, simply replace it with the three lines above. Otherwise, it should probably go before the first existing line ending in -j ACCEPT. Generally, you'll need to acquire some familiarity with the way iptables works, at which point the correct insertion point will be obvious.

Save that file, then say service iptables restart to reload the firewall rules. Be sure to do this while logged into the console, in case you fat-finger the edits! You don't want to lock yourself out of your machine while logged in over SSH.

The similarity to the commands above is no coincidence. Most of this file consists of arguments to the iptables command. The differences relative to the above are that the iptables command is dropped and the INPUT chain name becomes the special RHEL-specific RH-Firewall-1-INPUT chain. (If you care to examine the file in more detail, you'll see earlier in the file where they've essentially renamed the INPUT chain. Why? Couldn't say.)