At first blush, it looks like Debian is stretching the boundaries for sending an ICMP redirect; quoting RFC 792 (Internet Protocol).
The gateway sends a redirect message to a host in the following
situation. A gateway, G1, receives an internet datagram from a
host on a network to which the gateway is attached. The gateway,
G1, checks its routing table and obtains the address of the next
gateway, G2, on the route to the datagram's internet destination
network, X. If G2 and the host identified by the internet source
address of the datagram are on the same network, a redirect
message is sent to the host. The redirect message advises the
host to send its traffic for network X directly to gateway G2 as
this is a shorter path to the destination. The gateway forwards
the original datagram's data to its internet destination.
In this case, G1 is 10.1.2.1 (eth1:0 above), X is 10.1.1.0/24 and G2 is 10.1.1.12, and the source is 10.1.2.20 (i.e. G2 and the host identified by the internet source address of the datagram are **NOT** on the same network). Maybe this has been historically interpreted differently in the case of interface aliases (or secondary addresses) on the same interface, but strictly speaking I'm not sure we should see Debian send that redirect.
Depending on your requirements, you might be able to solve this by making the subnet for eth1 something like 10.1.0.0/22 (host addresses from 10.1.0.1 - 10.1.3.254) instead of using interface aliases for individual /24 blocks (eth1, eth1:0, eth1:1, eth1:2); if you did this, you'll need to change the netmask of all hosts attached and you wouldn't be able to use 10.1.4.x unless you expanded to a /21.
EDIT
We're venturing a bit outside the scope of the original question, but I'll help work through the design/security issues mentioned in your comment.
If you want to isolate users in your office from each other, let's step back for a second and look at some security issues with what you have now:
You currently have four subnets in one ethernet broadcast domain. All users in one broadcast domain doesn't meet the security requirements you articulated in the comments (all machines will see broadcasts from other machines and could spontaneously send traffic to each other at Layer2, regardless of their default gateway being eth1, eth1:0, eth1:1 or eth1:2). There is nothing your Debian firewall can do to change this (or maybe I should say there is nothing your Debian firewall should do to change this :-).
- You need to assign users into Vlans, based on security policy stated in the comments. A properly-configured Vlan will go a long way to fixing the issues mentioned above. If your ethernet switch doesn't support Vlans, you should get one that does.
- With respect to multiple security domains accessing
10.1.1.12, you have a couple of options:
- Option 1: Given the requirement for all users to access services on
10.1.1.12, you could put all users in one IP subnet and implement security policies with Private Vlans (RFC 5517), assuming your ethernet switch supports this. This option will not require iptables rules to limit intra-office traffic from crossing security boundaries (that is accomplished with private Vlans).
- Option 2: You could put users into different subnets (corresponding to Vlans) and implement
iptables rules to deploy your security policies
- After you have secured your network at the Vlan level, set up source-based routing policies to send different users out your multiple uplinks.
FYI, if you have a router that supports VRFs, some of this gets even easier; IIRC, you have a Cisco IOS machine onsite. Depending on the model and software image you already have, that Cisco could do a fantastic job isolating your users from each other and implement source-based routing policies.
Best Answer
You're leaving out a crucial piece of information, which is the subnet mask. You're making an incorrect assumption that these two hosts are in the same network/subnet based solely on the octet values without considering the subnet mask that each host is using. They could very well be in different networks.
Think of a house address. If I told you that I lived at 123 Smith Street would you know where my house is? No, you wouldn't. If I told you that I lived at 123 Smith Street in Smithtown would you know where my house is? No, you wouldn't. If I told you that John Smith also lives on Smith Street would you know if he and I are neighbors? No, you wouldn't. Even if I told you that John Smith also lives in Smithtown it's not possible for you to know if we're neighbors. If I told you that I lived at 123 Smith Street in Smithtown, Michigan 46123 would you know where my house is? Yes, you would. If I then told you that John Smith lives at 361 Smith Street in Smithtown, Michigan 46123 would you know if we're neighbors? Yes, you would know that we are in fact neighbors and live in the same neighborhood.
Knowing the IP address without knowing the subnet mask is like knowing my house address and street name without knowing the city, state and zip code. It's incomplete and doesn't give you enough information to know where my house is, or if a particular person also lives in my neighborhood.