mwan3: fix some tunnels assigned the wrong mark#20923
mwan3: fix some tunnels assigned the wrong mark#20923anyuta1166 wants to merge 3 commits intoopenwrt:masterfrom
Conversation
gentoo-root
left a comment
gentoo-root
left a comment
There was a problem hiding this comment.
Looks good to me (I don't have a setup with two tunnels to test it, though).
mwan3_pre and mwan3_post can be merged, both chains are identical.
Reference: https: //github.com/openwrt/pull/20923 Signed-off-by: bitthief <bitthief@protonmail.ch>
Reference: https: //github.com/openwrt/pull/20923 Signed-off-by: bitthief <bitthief@protonmail.ch>
Reference: https: //github.com/openwrt/pull/20923 Signed-off-by: bitthief <bitthief@protonmail.ch>
Reference: https: //github.com/openwrt/pull/20923 Signed-off-by: bitthief <bitthief@protonmail.ch>
Your issue is not related to this PR. This PR just adds a couple of iptables rules, it doesn't touch a routing table in any way. |
Reference: https: //github.com/openwrt/pull/20923 Signed-off-by: bitthief <bitthief@protonmail.ch>
|
@feckert Hi. Will this get merged? Seems like it solves a long standing issue? |
Reference: https: //github.com/openwrt/pull/20923 Signed-off-by: bitthief <bitthief@protonmail.ch>
Reference: https: //github.com/openwrt/pull/20923 Signed-off-by: bitthief <bitthief@protonmail.ch>
|
Just for adding another anecdote: for me the problem appears for traffic reaching the router via a VXLAN interface, which is running over a wireguard tunnel (which is connected via one of the WAN interfaces). I see the same problem: the traffic leaving the VXLAN interface is marked with I applied the patch from this pull request and now the routing of traffic looks good. Without that patch, I would be forced to separate the Thanks to @anyuta1166 for proposing the fix for this problem! |
|
@anyuta1166 @feckert still relevant? If so this needs a |
|
I don't have this problem in my setup. I would leave it open in case someone else has a problem. Due to lack of time, I haven't reviewed it yet. |
The mark of underlying tunnel connection is assigned to all incoming packets inside tunnel. This breaks mwan3 routing. Attempt to fix this by clearing the mark in incoming packets. Do not touch outgoing packets to make sure that tracking and "mwan3 use" command works as expected. Signed-off-by: Anna Tikhomirova <vamp@vampik.ru>
Signed-off-by: Anna Tikhomirova <vamp@vampik.ru>
The mark of outgoing connections propagates to the tunnel connection itself, which may break routing. Fix this by resetting the mark of outgoing packets after routing decision is made. Suggested-by: Maxim Mikityanskiy <maxtram95@gmail.com> Signed-off-by: Anna Tikhomirova <vamp@vampik.ru>
GeorgeSapkin
force-pushed
the
mwan3-mark-fix
branch
from
3524284 to
3eddb51
Compare
8 participants
The mark of underlying tunnel connection is assigned to all incoming packets inside tunnel. This breaks mwan3 routing. Attempt to fix this by clearing the mark in incoming packets. Do not touch outgoing packets to make sure that tracking and "mwan3 use" command works as expected.
Maintainer: @feckert
Compile tested: x86-64, OpenWrt master
Run tested: x86-64, OpenWrt master
Description:
There is an issue with some tunnels. The mark of underlying tunnel connection is assigned to all incoming packets inside tunnel. This breaks the routing, as replies to these packets may be sent to the wrong interface.
This applies, for example, to ipv6 tunnels (#14332 #18481), ipsec tunnels (#19607) and so on.
Fix this by resetting the mark in incoming packets.
This patch does not touch outgoing packets and doesn't break mwan3 wrapper library.
Fixes #14332 #18481 #19607