Re: [PATCH nf] netfilter REJECT: Fix destination MAC in RST packets

["Marc Aurèle La France" <tsi@tuyoix.net>]

[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]

On Mon, 8 Mar 2021, Pablo Neira Ayuso wrote:
> On Sun, Mar 07, 2021 at 06:16:34PM -0700, Marc Aurèle La France wrote:
>> In the non-bridge case, the REJECT target code assumes the REJECTed
>> packets were originally emitted by the local host, but that's not
>> necessarily true when the local host is the default route of a subnet
>> it is on, resulting in RST packets being sent out with an incorrect
>> destination MAC.  Address this by refactoring the handling of bridged
>> packets which deals with a similar issue.  Modulo patch fuzz, the
>> following applies to v5 and later kernels.

> The code this patch updates is related to BRIDGE_NETFILTER. Your patch
> description refers to the non-bridge case. What are you trying to
> achieve?

Via DHCP, my subnet's default route is a Linux system so that it can 
monitor all outbound traffic.  By doing so, for example, I have determined 
that my Android phone connects to Facebook despite the fact that I have no 
such app installed.  I want to know, and control, what other 
behind-the-scenes (under-handed) traffic devices on my subnet generate.

> dev_queue_xmit() path should not be exercised from the prerouting
> chain, packets generated from the IP later must follow the
> ip_local_out() path.

Well, I can tell you dev_queue_xmit() does in fact work in prerouting 
chains, as it must for the bridging case.  The only potential problem I've 
found so far is that the RST packet doesn't go through any netfilter 
hooks.

Marc.