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
