Wow, thank you Mart! I didn't really think that the rp_filter would have
anything to do with it, but in fact it had! Even though I had disabled
for "all" interfaces, it seems that the rp_filter files for each
interface overlaps "all".
So,
echo 0 > /proc/sys/net/ipv4/conf/eth2/rp_filter
solved the problem of disappearing packets.
But unlike the eth1 interface, the RELATED state isn't allowing (or
recognizing) the data channel. After doing a DNAT from port 49152 to
65535, the default data ports for MS FTP, I can now successfully connect
through the second interface. I don't think there's a workaround for
that, right?
Even so, I'm glad you guys could help me.
Thanks a lot!
Em 09/05/2014 18:32, Mart Frauenlob escreveu:
On 09.05.2014 23:07, netfilter-owner@xxxxxxxxxxxxxxx wrote:
No deal yet. After inserting the new routing tables and rules it didn't
really change anything.
The eth2 doesn't have a gateway set in the config file, only eth1 have
it. Plus, these two interfaces are in the same subnet and there's only
one gateway on it (180.1.2.1).
[root@firewall ~]# ip route show table T1
default via 180.1.2.1 dev eth1
[root@firewall ~]# ip route show table T2
default via 180.1.2.1 dev eth2
[root@firewall ~]# ip rule show
0: from all lookup local
10: from 180.1.2.11 lookup T1
20: from 180.1.2.12 lookup T2
32766: from all lookup main
32767: from all lookup default
(I had to add the tables T1 and T2 in the file /etc/iproute2/rt_tables)
Even so, I see it reach the PREROUTING chain in eth2 but it still
disappears after that. Connections reaching in the eth1 still works.
There's something else to try?
Check values of /proc/sys/net/ipv4/conf/*/rp_filter
and disable them.
To use the TRACE target just put a -j TRACE on the desired place.
--
To unsubscribe from this list: send the line "unsubscribe netfilter" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
