routing through multiple subinterfaces in debian

Question

my question is as simple as the title, i have a debian 6 , 2 NICs, 3 different subnets in a single interface, just like this:

auto eth0
iface eth0 inet static
    address 192.168.106.254
    netmask 255.255.255.0

auto eth0:0
iface eth0:0 inet static
    address 172.19.221.81
    netmask 255.255.255.248

auto eth0:1
iface eth0:1 inet static
    address 192.168.254.1
    netmask 255.255.255.248

auto eth1
iface eth1 inet static
    address 172.19.216.3
    netmask 255.255.255.0
    gateway 172.19.216.13

eth0 is conected to a swith with 3 differents vlans, eth1 is conected to a router. No iptables DROP, so, all traffic is allowed. Now, passing the traffic through eth0 is OK, passing the traffic through eth0:0 is OK, but, passing the traffic through eth0:1 is not working, i can ping the ip address of that sub interface from a pc where this ip is the default gateway, but can't get to servers in the subnet of the eth1 interface, the traffic is not passing, even when i set the iptables to log all the traffic in the FORWARD chain and i can see the traffic there, but, the traffic is not really passing. And the funny is i can do any the other way around, i mean, passing from eth1 to eth0:1, RDP, telnet, ping, etc,

doing some work with the iptable, i manage to pass some traffic from eth0:1 to eth1, the iptables look like this:

iptables -t nat PREROUTING -d 192.168.254.1/32 -p tcp -m multiport --dports 25,110,5269 -j DNAT --to-destination 172.19.216.1
iptables -t nat PREROUTING -d 192.168.254.1/32 -p udp -m udp --dport 53 -j DNAT --to-destination 172.19.216.9
iptables -t nat PREROUTING -d 192.168.254.1/32 -p tcp -m tcp --dport 21 -j DNAT --to-destination 172.19.216.11

iptables -t nat POSTROUTING -s 172.19.216.0/24 -d 172.19.221.80/29 -j SNAT --to-source 172.19.221.81
iptables -t nat POSTROUTING -s 172.19.216.0/24 -d 192.168.254.0/29 -j SNAT --to-source 192.168.254.1
iptables -t nat POSTROUTING -s 172.19.216.0/24 -o eth0 -j SNAT --to-source 192.168.106.254

dong this is working, but,it is really a headache have to map each port with the server, imagine if i move the service from server, so, now i have doubts:
can debian route through multiple subinterfaces?? exist a limit for this?? if not, what i'm doing wrong when i have the same setup with other subnets and it is working ok?? without the iptables rules in the nat, it doesn't work

thanks and i hope good comments/answers

ROUTES in 172.19.216.3

root@dbf1:~# ip route
192.168.254.0/29 dev eth0  proto kernel  scope link  src 192.168.254.1
172.19.221.80/29 dev eth0  proto kernel  scope link  src 172.19.221.81
172.19.216.0/24 dev eth1  proto kernel  scope link  src 172.19.216.3
192.168.106.0/24 dev eth0  proto kernel  scope link  src 192.168.106.254
default via 172.19.216.13 dev eth1

Solution

When a machine wants to send a packet to a destination for which it has no route, it forwards it to its default gateway. The machines you are trying to reach are doing this with the reply packets they are generating. If that default gateway machine they are using doesn't know how to reach this machine, then it will appear as if this machine isn't sending the traffic properly. But it is. The issue is in the replies not getting back.

This is the sequence:

1. This machine sends the packet to the correct machine.

2. The destination machine gets the packet and forms a response. The IP destination of the response is the source of the packet it received.

3. The destination machine has no route to the destination of this packet, since it's not on the local subnet. So it forwards it to its default gateway router.

4. That router has no idea how to reach that destination, since it's not on its subnet either. So it sends it over its default gateway, likely the Internet.

For a network to work properly, any device that's any machine's default gateway has to know how to reach every local subnet any of its clients might wish to reach or each of those clients must have its own method to reach that subnet.

Comments

[Zoredache]

I am a bit confused about you mentioning VLANs, but you haven't don anything in your config interfaces file to set the VLAN ID. What does the route table look like on 172.19.216.13? Does it have a route for the 192.168.254.0/29 network? Have you setup your switch for VLAN trunking? What are the VLAN IDs for the various networks?

[David Schwartz]

Most likely, the issue has nothing to do with this machine and is in the destination machines. If they (or their default gateway) have no idea how to get the reply traffic to this machine, then the symptoms will appear substantially the same as if this machine wasn't sending the traffic. But likely it is, and it's reaching its destination.

[Castro Roy]

I don't think that the issue is in the destination, as i said in the question, i can go the other way around, for example, from a server in the lan 172.19.216.0/24, i can ping 192.168.254.2 and get a response as the default gateway is 172.19.216.3, but can't ping from 192.168.254.2 to 172.19.216.1 without the rules in the PREROUTING, and this is what i don't understand.

[Castro Roy]

i post the route table in 172.19.216.13

[Castro Roy]

ok, i got your point, but, why with the iptables rules works, and without it doesn't? why from a server in the lan 172.19.216.0/24, i can ping 192.168.254.2 and get a response as the default gateway is 172.19.216.3, but can't ping from 192.168.254.2 to 172.19.216.1 without the rules in the PREROUTING, here are my doubts, what i'm doing wrong, you can check the route table that i post above, thanks for the response.

[David Schwartz]

With the rules, the destination machine doesn't need to be able to reach the source machine because the router impersonates the source machine. Without the rules, the destination machine does need such a route, and it doesn't have one.

[Castro Roy]

the destination does have the route, because the default gateway is 172.19.216.3, if i do the same the oder way around, think that the source now is 172.19.216.1 and destination is 192.168.254.2, even without the iptables rules, it works, but, not vice versa.