netdev - Re: [PATCH net-next 4/8] ovpn: Allow IPv6 link-local addresses through RPF check

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 for Android: free password hash cracker in your pocket

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

Message-ID: <819ccede-6edf-49d4-b07f-a973552e02a9@openvpn.net>
Date: Tue, 18 Nov 2025 11:26:19 +0100
From: Antonio Quartulli <antonio@...nvpn.net>
To: Sabrina Dubroca <sd@...asysnail.net>
Cc: netdev@...r.kernel.org, Eric Dumazet <edumazet@...gle.com>,
 Jakub Kicinski <kuba@...nel.org>, Paolo Abeni <pabeni@...hat.com>,
 Ralf Lici <ralf@...delbit.com>
Subject: Re: [PATCH net-next 4/8] ovpn: Allow IPv6 link-local addresses
 through RPF check

On 14/11/2025 17:06, Sabrina Dubroca wrote:
> 2025-11-11, 22:47:37 +0100, Antonio Quartulli wrote:
>> From: Ralf Lici <ralf@...delbit.com>
>>
>> IPv6 link-local addresses are not globally routable and are therefore
>> absent in the unicast routing table. This causes legitimate packets with
>> link-local source addresses to fail standard RPF checks within ovpn.
>>
>> Introduce an exception to explicitly allow such packets as link-local
>> addresses are essential for core IPv6 link-level operations like NDP,
>> which must function correctly within the virtual tunnel interface.
> 
> Does this fix an existing bug, or does it only become a problem for
> some of the new features in that series (multipeer-to-multipeer?)? If
> this is a problem for existing use-cases, there should be a Fixes tag.
> 

Actually, after having spent more time on this patch, we realized that 
this patch is not really needed, because we can't truly route packets to 
addresses that are not known to ovpn (we wouldn't know which peer to 
send them to).

Hence this is a change that we originally thought to be needed, but 
further tests proved what I said above.

I'll drop this patch from the next PR.

Regards,


-- 
Antonio Quartulli
OpenVPN Inc.