Difficulties with iptables and multihoming

[kristrev]

Hello,

I am working on a small project where I have a device with two network interfaces attached to the same subnet, iface1 and iface2. Some of the packets that arrive on iface1 should be forwarded to iface2 and I have written a rule using iptables. I see that the rule match (using LOG), but the packets seem to disappear after the PREROUTING-step (I have tried logging all possible combinations in both INPUT and FORWARD).

To allow each device access to the rest of the network, I have had to modify the routing table significantly (attached at the bottom) and I think maybe that the system gets confused during the ROUTING-step. It seems like the kernel does not understand that the new destination address is local and simply discards the packet, neither pinging the interface nor netcat (run from one another) works or give any reply.

If anyone have any tips, I would be very grateful.

Thanks in advance,
Kristian

Main routing table:

192.168.100.0/23 dev eth0  scope link  src 192.168.101.14 
192.168.100.0/23 dev eth1  scope link  src 192.168.100.250  metric 10 
default via 192.168.100.1 dev eth0 
default via 192.168.100.1 dev eth1  metric 10

192.168.100.0   0.0.0.0         255.255.254.0   U     0      0        0 eth0
192.168.100.0   0.0.0.0         255.255.254.0   U     10     0        0 eth1
0.0.0.0         192.168.100.1   0.0.0.0         UG    0      0        0 eth0
0.0.0.0         192.168.100.1   0.0.0.0         UG    10     0        0 eth1

Table T_eth0:

192.168.100.0/23 dev eth0  scope link  src 192.168.101.14 
default via 192.168.100.1 dev eth0

Table T_eth1:

192.168.100.0/23 dev eth1  scope link  src 192.168.100.250 
default via 192.168.100.1 dev eth1

IP Rules:

0:      from all lookup local 
32764:  from 192.168.100.250 lookup T_eth1 
32765:  from 192.168.101.14 lookup T_eth0 
32766:  from all lookup main 
32767:  from all lookup default

[kristrev]

Turned out that rp_filter was the cause of the problem, when disabling that everything works perfectly. However, I guess that is to wise from a security perspective, so if anyone have any suggestions I am eager to hear them.