* ipt_reject.c --> ip_route_me_harder ... --> ip_route_output_slow: iif is loopback device? @ 2010-05-11 10:28 s sg 2010-05-11 10:59 ` Pascal Hambourg 0 siblings, 1 reply; 6+ messages in thread From: s sg @ 2010-05-11 10:28 UTC (permalink / raw) To: netfilter Hi, 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. 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. I am confused why iif is hard-coded to loopback device but not the real iif of the packet in ip_route_output_slow. I try to use the real iif of the packet, then everything is fine: RST packet can be routed correctly. But I am new to the routing stuff and not sure if this solution is ok, can some one kindly explain a little on this? Thank you in advance! group1\ /wan1 \ / \ / -|----------------|- | linux box | | ( 2.6.20 ) | -|----------------|- / \ / \ group2/ \wan2 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ipt_reject.c --> ip_route_me_harder ... --> ip_route_output_slow: iif is loopback device? 2010-05-11 10:28 ipt_reject.c --> ip_route_me_harder ... --> ip_route_output_slow: iif is loopback device? s sg @ 2010-05-11 10:59 ` Pascal Hambourg 2010-05-11 14:45 ` Eason Su 0 siblings, 1 reply; 6+ messages in thread From: Pascal Hambourg @ 2010-05-11 10:59 UTC (permalink / raw) To: s sg; +Cc: netfilter 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ipt_reject.c --> ip_route_me_harder ... --> ip_route_output_slow: iif is loopback device? 2010-05-11 10:59 ` Pascal Hambourg @ 2010-05-11 14:45 ` Eason Su 2010-05-11 16:27 ` ratheesh k 0 siblings, 1 reply; 6+ messages in thread From: Eason Su @ 2010-05-11 14:45 UTC (permalink / raw) To: Pascal Hambourg; +Cc: netfilter 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. > 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. > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ipt_reject.c --> ip_route_me_harder ... --> ip_route_output_slow: iif is loopback device? 2010-05-11 14:45 ` Eason Su @ 2010-05-11 16:27 ` ratheesh k 2010-05-11 17:54 ` ratheesh k 0 siblings, 1 reply; 6+ messages in thread From: ratheesh k @ 2010-05-11 16:27 UTC (permalink / raw) To: Eason Su; +Cc: Pascal Hambourg, netfilter On Tue, May 11, 2010 at 8:15 PM, Eason Su <ssg2351@gmail.com> 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@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ipt_reject.c --> ip_route_me_harder ... --> ip_route_output_slow: iif is loopback device? 2010-05-11 16:27 ` ratheesh k @ 2010-05-11 17:54 ` ratheesh k 2010-05-13 14:41 ` Eason Su 0 siblings, 1 reply; 6+ messages in thread From: ratheesh k @ 2010-05-11 17:54 UTC (permalink / raw) To: Eason Su; +Cc: Pascal Hambourg, netfilter 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@gmail.com> wrote: > On Tue, May 11, 2010 at 8:15 PM, Eason Su <ssg2351@gmail.com> 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@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html >> > ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: ipt_reject.c --> ip_route_me_harder ... --> ip_route_output_slow: iif is loopback device? 2010-05-11 17:54 ` ratheesh k @ 2010-05-13 14:41 ` Eason Su 0 siblings, 0 replies; 6+ messages in thread From: Eason Su @ 2010-05-13 14:41 UTC (permalink / raw) To: ratheesh k; +Cc: Pascal Hambourg, netfilter Hi ratheesh, I think the issue you met may not have relation with ipt_reject + policy routing, so let's talk in a separate mail ^_^. Hi all, ipt_reject.c using ip_route_output_key (in ip_route_me_harder) to get RST packet's reverse path's oif may have problem if system has "from iif xxx" policy routing. Anyone comment on it? Or anyone could kindly give me some clue on ipt_reject + policy routing scenario? Thanks. 2010/5/12 ratheesh k <ratheesh.ksz@gmail.com>: > 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@gmail.com> wrote: >> On Tue, May 11, 2010 at 8:15 PM, Eason Su <ssg2351@gmail.com> 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@vger.kernel.org >>> More majordomo info at http://vger.kernel.org/majordomo-info.html >>> >> > ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-05-13 14:41 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-05-11 10:28 ipt_reject.c --> ip_route_me_harder ... --> ip_route_output_slow: iif is loopback device? s sg 2010-05-11 10:59 ` Pascal Hambourg 2010-05-11 14:45 ` Eason Su 2010-05-11 16:27 ` ratheesh k 2010-05-11 17:54 ` ratheesh k 2010-05-13 14:41 ` Eason Su
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox