diff mbox series

[Openvpn-devel,ovpn-net-next] ovpn: don't drop skb's dst when xmitting packet

Message ID 20250507085632.15329-1-a@unstable.cc
State New
Headers show
Series [Openvpn-devel,ovpn-net-next] ovpn: don't drop skb's dst when xmitting packet | expand

Commit Message

Antonio Quartulli May 7, 2025, 8:56 a.m. UTC 
From: Antonio Quartulli <antonio@openvpn.net>

When routing a packet to a LAN behind a peer, ovpn need to
inspect the route entry that brought there the packet in the
first place.

If this packet is truly routable, the route will provide the
GW to be used to lookup the VPN peer to send the packet to.

However, the route entry is currently dropped before entering
the ovpn xmit function, because the IFF_XMIT_DST_RELEASE priv_flag
is set by default.

Clear the IFF_XMIT_DST_RELEASE flag during interface setup to allow
the route entry (skb's dst) to survive and thus be inspected
by the routing logic.

Reported-by: Gert Doering <gert@greenie.muc.de>
Signed-off-by: Antonio Quartulli <antonio@openvpn.net>
---
 drivers/net/ovpn/main.c | 5 +++++
 1 file changed, 5 insertions(+)

Comments

Gert Doering May 7, 2025, 9:11 a.m. UTC | #1 
Hi,

On Wed, May 07, 2025 at 10:56:32AM +0200, Antonio Quartulli wrote:
> Clear the IFF_XMIT_DST_RELEASE flag during interface setup to allow
> the route entry (skb's dst) to survive and thus be inspected
> by the routing logic.

Tested, fixes the problem I reported in

  https://github.com/OpenVPN/ovpn-net-next/issues/2

... and is also the arguably correct thing to do - packet forwarding
resolves a next-hop for us, so we should ensure we see & use it :-)

Tested-by: Gert Doering <gert@greenie.muc.de>
Acked-by: Gert Doering <gert@greenie.muc.de>

gert
Antonio Quartulli May 7, 2025, 7:39 p.m. UTC | #2 
On 07/05/2025 11:11, Gert Doering wrote:
> Hi,
> 
> On Wed, May 07, 2025 at 10:56:32AM +0200, Antonio Quartulli wrote:
>> Clear the IFF_XMIT_DST_RELEASE flag during interface setup to allow
>> the route entry (skb's dst) to survive and thus be inspected
>> by the routing logic.
> 
> Tested, fixes the problem I reported in
> 
>    https://github.com/OpenVPN/ovpn-net-next/issues/2
> 
> ... and is also the arguably correct thing to do - packet forwarding
> resolves a next-hop for us, so we should ensure we see & use it :-)
> 
> Tested-by: Gert Doering <gert@greenie.muc.de>
> Acked-by: Gert Doering <gert@greenie.muc.de>
> 

Merged to main branch, commit id 7618f9707173

Thanks!
diff mbox series

Patch

diff --git a/drivers/net/ovpn/main.c b/drivers/net/ovpn/main.c
index 0acb0934c1be..e17992b937bc 100644
--- a/drivers/net/ovpn/main.c
+++ b/drivers/net/ovpn/main.c
@@ -157,6 +157,11 @@  static void ovpn_setup(struct net_device *dev)
 	dev->type = ARPHRD_NONE;
 	dev->flags = IFF_POINTOPOINT | IFF_NOARP;
 	dev->priv_flags |= IFF_NO_QUEUE;
+	/* when routing packet to a LAN behind a client, we rely on the
+	 * route entry that originally brought the packet into ovpn, so
+	 * don't release it
+	 */
+	dev->priv_flags &= ~IFF_XMIT_DST_RELEASE;
 
 	dev->lltx = true;
 	dev->features |= feat;