netdev - [question] rp_filter=1 ~implies arp

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <4577a5aa-0d95-accd-f581-e1f25b0fcd68@ziu.info>
Date:   Thu, 9 May 2019 18:17:48 +0200
From:   Michal Soltys <soltys@....info>
To:     linux-netdev <netdev@...r.kernel.org>
Subject: [question] rp_filter=1 ~implies arp_filter

Hi,

This got me a bit surprised actually and I'm wondering if it's intended. 
While both options are somewhat similar in their function, they do 
different things after all (and for different protocols):

- arp_filter - whether all interfaces should consider responding for arp 
request (which then can be further tuned by arp_ignore whether they 
actually should reply)

- rp_filter (=1) - will discard ip packets incoming on interface that is 
not considered the best

But it seems rp_filter (=1) also either nukes arp or inhibits arp reply. 
For example:

::In 1st namespace:

a2    inet 192.168.77.88/24 scope global a2
b2    inet 192.168.77.89/24 scope global b2

192.168.77.0/24 dev b2 proto kernel scope link src 192.168.77.89
192.168.77.0/24 dev a2 proto kernel scope link src 192.168.77.88 metric 20

So 77.89 is "better" in route context.

rp_filter=1
arp_filter=0
arp_ignore=1

::In 2nd namespace:

a1 and b1 enslaved to bridge brX with address 192.168.77.77/24

In such scenario, doing from this namespace:

arping -b -I brX 192.168.77.89 - works as expected with replies from 
192.168.77.89's interface

arping -b -I brX 192.168.77.88 - nothing

Setting arp_ignore=0 (in 1st namespace) would (as expected) give replies 
in both cases from 192.168.77.89's interface only.