Re: ipt_reject.c --> ip_route_me_harder ... --> ip_route_output_slow: iif is loopback device?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Netfilter Development]     [Linux Kernel Networking Development]     [Netem]     [Berkeley Packet Filter]     [Linux Kernel Development]     [Advanced Routing & Traffice Control]     [Bugtraq]

  Powered by Linux