By default, on Linux, if an interface has multiple addresses that are on different subnets, traffic destined for the respective subnets will have the proper source IP. That is, if eth0 has two addresses 192.168.1.1/24 and 10.1.1.1/8, then traffic to anything on the 10.0.0.0 subnet will have source 10.1.1.1, and traffic to anything on the 192.168.1.0 subnet will have source 192.168.1.1. You can also assign source addresses explicitly in this case by using the "src 1.2.3.4" option to "ip route".
In your case, though, all your addresses are on the same subnet, so the "primary" one (as revealed by "ip addr list dev eth0") is used as the source IP for traffic exiting on that interface. I think it's possible to control the source IPs in this case just using "ip route", but I've found it easier to use iptables to rewrite the source addresses for traffic of interest.
If you want to force a specific source address to be used for specific destinations, you can do it with a SNAT rule:
iptables -t nat -I POSTROUTING -o eth0 -d dest-IP-or-net/mask -s primary-IP-of-eth0 -j SNAT --to-source desired-source-IP
So if your "primary" eth0 IP is 192.168.100.1, but you want traffic to 1.2.3.4 to have a source of 192.168.100.2, then do this:
iptables -t nat -I POSTROUTING -o eth0 -d 1.2.3.4/0 -s 192.168.100.1 -j SNAT --to-source 192.168.100.2
Note that the "-s 192.168.100.1" is important: it prevents forwarded traffic's source addresses being rewritten by this rule.
If you are going to implement complex network configurations on Linux, you should read the Linux Advanced Routing and Traffic Control documentation, http://lartc.org
Just add the following:
-A INPUT -p tcp --dport 2020 -m state --state NEW -j ACCEPT
... right after these two lines:
-A INPUT -p tcp --dport 2020 -m state --state NEW -m recent --set --name SSH
-A INPUT -p tcp --dport 2020 -m state --state NEW -m recent --update --seconds 120 --hitcount 8 --rttl --name SSH -j DROP
Also, you should think about a cron task that will clean your /proc/net/ipt_recent/SSH (ipt_recent may be xt_recent on newer platforms) from time to time, in case you get locked out.
EDIT: Your rule ordering looks a bit odd to me, if I were you I would go with something like this:
*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
# Loopback interface
-A INPUT -i lo -j ACCEPT
# ICMP traffic
-A INPUT -p icmp --icmp-type any -j ACCEPT
# Already established connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# SSH
-A INPUT -p tcp --dport 2020 -m state --state NEW -m recent --set --name SSH
-A INPUT -p tcp --dport 2020 -m state --state NEW -m recent --update --seconds 120 --hitcount 8 --rttl --name SSH -j DROP
-A INPUT -p tcp --dport 2020 -m state --state NEW -j ACCEPT
# Web services
-A INPUT -p tcp --dport 80 -m state --state NEW -j ACCEPT
-A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
-A INPUT -p tcp --dport 8088 -m state --state NEW -j ACCEPT
# Reject everything else
-A INPUT -j REJECT --reject-with icmp-host-prohibited
COMMIT
Best Answer
There is no one answer.
tail -fon the log is useful to see if connections are getting processed properly.Which solution is appropriate depends on your needs. You may choose to use more than one solution.