When dealing with network security, there are frequent cases where you need to allow access from an entire IP range rather than individual addresses. The 10.51.x.x range mentioned represents a private class A network where you might want to permit all internal traffic while maintaining other restrictions.

The correct way to allow an entire range in iptables is using CIDR notation. For the 10.51.x.x network (which covers 10.51.0.0 to 10.51.255.255), we use the subnet mask 10.51.0.0/16.

# Allow entire 10.51.x.x range on ETH1
-A INPUT -i eth1 -s 10.51.0.0/16 -j ACCEPT

The placement of rules in iptables is crucial. This rule should come after your loopback and established connection rules, but before your final REJECT rule:

-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 ! -i lo -j REJECT --reject-with icmp-port-unreachable
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Insert our range rule here
-A INPUT -i eth1 -s 10.51.0.0/16 -j ACCEPT

# Continue with other rules
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

For more granular control, you can combine the IP range restriction with specific protocols or ports:

# Allow SSH only from the 10.51 range on eth1
-A INPUT -i eth1 -s 10.51.0.0/16 -p tcp --dport 22 -j ACCEPT

# Allow HTTP/HTTPS from same range
-A INPUT -i eth1 -s 10.51.0.0/16 -p tcp --dport 80 -j ACCEPT
-A INPUT -i eth1 -s 10.51.0.0/16 -p tcp --dport 443 -j ACCEPT

After making changes, verify them with:

iptables -L -n -v

Look for your new rules in the INPUT chain and check the packet counters to confirm they're being hit.

Remember to save your iptables rules to make them persistent across reboots. On most systems:

iptables-save > /etc/iptables.rules

Then configure your system to load them at boot (method varies by distribution).

When administering Linux servers, you'll often need to restrict access to specific network ranges. In this case, we're focusing on allowing all IPs in the 10.51.0.0/16 range (10.51.x.x) on interface ETH1.

Your existing configuration shows standard rules for common services (SSH, HTTP, HTTPS, email ports), but lacks specific interface-based rules for the 10.51.x.x network:

# Current INPUT chain rules
-A INPUT -i lo -j ACCEPT
-A INPUT -d 127.0.0.0/8 ! -i lo -j REJECT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
# ... other service rules ...

To allow the entire 10.51.0.0/16 subnet on ETH1, add this rule before your REJECT policies:

# Allow all traffic from 10.51.x.x on ETH1
-A INPUT -i eth1 -s 10.51.0.0/16 -j ACCEPT

For more granular control, you can combine with specific ports:

# Allow only SSH from 10.51.x.x on ETH1
-A INPUT -i eth1 -s 10.51.0.0/16 -p tcp --dport 22 -j ACCEPT

# Allow HTTP/HTTPS from specific sub-range
-A INPUT -i eth1 -s 10.51.100.0/24 -p tcp -m multiport --dports 80,443 -j ACCEPT

1. Position matters: Place range rules before generic REJECT/DROP rules
2. Be specific: Prefer subnet masks like /24 over broader /16 when possible
3. Document rules: Add comments explaining each range's purpose
4. Combine with state tracking: -m state --state NEW for initial connections

After applying changes, verify with:

iptables -L -n -v | grep 10.51.0.0/16

Test connectivity from a 10.51.x.x host while monitoring logs:

tail -f /var/log/syslog | grep iptables

Here's how your ruleset might look with the new additions:

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:fail2ban-ssh - [0:0]

# Custom IP range rules
-A INPUT -i eth1 -s 10.51.0.0/16 -j ACCEPT

# Existing rules
-A INPUT -p tcp -m multiport --dports 22 -j fail2ban-ssh
-A INPUT -i lo -j ACCEPT
# ... rest of your existing rules ...
COMMIT