My question is : what will happen to ping responses ? it will be routed correctly. Thanks, Ratheesh On Tue, May 11, 2010 at 9:57 PM, ratheesh k <ratheesh.ksz@xxxxxxxxx> wrote: > On Tue, May 11, 2010 at 8:15 PM, Eason Su <ssg2351@xxxxxxxxx> wrote: >> Hi Pascal, >> >> Thanks for your reply! The RST packet should be sent back via the same >> interface (group2), that is what REJECT with RST target do. >> >> ip_route_me_harder include two routines, ip_route_output_key and >> ip_route_input. ip_route_output_key is to find the wanX which is used >> for reverse path filtering in ip_route_input. >> >> And I get the wrong wanX from ip_route_output_key because iif is set >> to loopback device but not the real device that the packet comes from, >> so the reverse path checking fail in ip_route_input. So ip_route_input >> fail, ip_route_me_harder fail. >> >> If I disable reverse path filtering(echo >> 0>/proc/sys/net/ipv4/conf/wanX/rp_filter), everything will be ok too: >> ip_route_input ok, ip_route_me_harder ok, send_rst in ipt_REJECT.c ok. >> >> I kind of not agree about ip_route_me_harder use ip_route_output_key >> to get reverse path device, is it possible that ip_route_me_harder not >> use ip_route_output_key to get reverse path device but just do some >> trick to let ip_route_input not do the reverse path checking, or do >> the right checking? Obviously echo >> 0>/proc/sys/net/ipv4/conf/wanX/rp_filter is not an option. > > will this affect icmp ping request also ? . > > -Ratheesh > >> >> >>> Hello, >>> >>> s sg a écrit : >>>> >>>> I meet a routing issue when I try to use ipt_reject RST target in my >>>> policy routing enabled linux box (please see below picture). >>>> >>>> The linux box is configured to support policy routing, iif policy. The >>>> policy is, if packet is from interface group1, then it will lookup >>>> table 100, this table's default oif is wan1. And if packet is from >>>> interface group2, then it will lookup table 101, this table's default >>>> oif is wan2. The main table's default oif is wan1. >>>> >>>> The issue is, one packet comes from group2 and then ipt_reject wants >>>> to send RST, but the routing for the RST packet fail >>>> (ip_route_me_harder fail). >>>> >>>> I trace the code in ipt_REJECT.c. ipt_REJECT.c use ip_route_me_harder >>>> to find the RST packet's destination. ip_route_me_harder will first >>>> find the RST packet's reverse path using ip_route_output_key. The >>>> trace of ip_route_output_key is like this: >>>> ip_route_me_harder --> ip_route_output_key --> ip_route_output_flow >>>> --> __ip_route_output_key --> ip_route_output_slow. >>>> >>>> In ip_route_output_slow, before fib_lookup, the iif is set to lookback >>>> device, not the real device where the packet comes. >>> >>> This is expected behaviour. The RST packet is locally generated, and as >>> such has iif set to the loopback device. >>> >>>> So the policy >>>> finding in fib_lookup will fail to find table 101 but fall to main >>>> table, so the oif is wan1 but not wan2. >>> >>> There is one thing I don't understand. The RST packet is generated in >>> reply to a packet that was received on interface group2, so I would >>> expect that it sent back via that same interface, not on any wan >>> interface. Anyway, it does not matter what interface the original packet >>> was supposed to be forwarded to. >>> >> -- >> 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 >> > -- 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