wireguard can't handshake with mwan3 #9538
Comments
|
did you tried to add a rule so a specific port/udp to only use one interface ? you can find it in web interface |
The wireguard itself can't bind to specific interface, and I've tried to specific 5888 port only use one interface, but it didn't work. |
|
This is because the wireguard runs directly on the router. For outgoing router traffic the nat prerouting hook is not passed through by the firewall, because it does not exist! Only for forwarded traffic. So a rule for on mwan3 for router traffic make no sense. |
So there is no way to get wireguard working with mwan3? |
|
My guess is that wireguard kernel module selects a source address to use after looking up routes. It does not record which dst addr it previously received peer traffic and send response from that address. If that's what happened, try to connect to the server by address |
The |
Then very likely my guess is right ;) Note that the use of udp as transport plays a role here. Many user space services use IP_PKTINFO for fetching the local address it received the msg and send response from the same address. The issue will need to be handled by the wireguard kernel module.
Yes, I am ;) |
|
@yousong |
|
After searching it a bit more, I found that WireGuard designers already took the issue into consideration [1]. There should be other causes. [1] see the slide about "Sticky Sockets", https://www.wireguard.com/talks/eindhoven2018-slides.pdf EDIT: my email address should be available in my github profile page, or the git log |
|
Maybe try adding a source based policy route rule where N should be the route table number corresponding to |
Tried this, but it wasn't working. I think wireguard just use the main routing table. |
|
It's generic linux route lookup. It should work. Just to be sure, please share the output of the following commands |
|
@yousong |
|
Hmm, I cannot see where the problem is. The I am curious and had an experiment [1]. Hope it helps. [1] https://gist.github.com/yousong/e6ebd3c9f838286d6fda3228655c1f90 |
I think it won't work, in my opinion the source address is fixed by the wireguard when wireguard reply the handshake data, the |
|
My wireguard config: |
|
And the server side configuration? |
This is the server side configuration... |
Hello, wackejohn, 我遇到与你同样的issue发生在使用UDP协议上的OpenVPN。 |
配置OpenVPN监听在lan口，该问题就解决了，wireguard目前只能监听在0.0.0.0，所以目前来说似乎无解。。。 mwan3官方文档：https://openwrt.org/docs/guide-user/network/wan/multiwan/mwan3#openvpn |
非常感谢你给出的指引。 |
|
@fox85 @wackejohn |
Sorry. @feckert , thanks @wackejohn has translated my issue to english. :) |
|
@wackejohn @fox85 If the problem persists please reopen the ticket |
|
I had the same issue with my mwan3 config balancing 2 WAN with 50/50 rule.
Please put corresponding ifmark for your wireguard listening WAN interface. As I have traced the packets, issue happens on PREROUNTING -> wman3_hook chain. Incoming handshake packet from WAN1 came to the router and wman decided to mark it with 0x100 or 0x200 - after that, the whole connection will have same mark. |
|
@psergei |
|
Yeah, for what it's worth I ran into this issue with multiwan on opnsense
as well, so this is hardly exclusive to mwan3. Weird that the wireguard
devs are being Like this.
…On Mon, Jan 3, 2022 at 6:59 AM wackejohn ***@***.***> wrote:
@feckert <https://github.com/feckert>
As I said above, the wireguard team refuse to fix it (actually these years
there were a lot of talks about this in the wireguard mailing list, but the
wireguard team never fix), so I try to fix this issue in my owen way. For
now, the only thing is if there is a bettery way to mark the wireguard
incoming connection in mwan3. Many Thanks.
—
Reply to this email directly, view it on GitHub
<#9538 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACFNSCMBR2H5GTHIAJIRNP3UUGFRJANCNFSM4IFXU2LQ>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
You are receiving this because you commented.Message ID:
***@***.***>
--
Andrew Donshik
Sent From G-Mail
|
|
Tried to add a switch for saving the fwmark, or it will break the wireguard outgoing rule configured by mwan3. wireguard_fwmark_hack.patch : And wireguard-tools also need to patch, wireguard-tools-with-savemark-hack.patch : |
|
@feckert I'm not good at coding, my patch was only tested for my use cases, hoping improvements for this patch. The patch: |
|
Patch improved: The previous patch would break the wireguard out going packets when the wan ip changed. And now this patch can capture the incoming wan ip as the souce ip, and also work with the mwan3 out going rules. |
|
If you have a patch for wireguard, can you please submit it upstream with the wireguard developers? We are not really equipped to do a proper security audit that would be necessary to accept a P/R that touches the core wireguard code. |
Hi, |
|
@wackejohn Most of the patches and changes are over my head in terms of understanding, but certainly appreciate your efforts. I'd hope the Wireguard devs would reconsider them, given I think Wireguard does have issues with multi WAN environments. |
|
@jamesmacwhite I've hoped for years already, but nothing happend, then I have to try it myself. All of my thinking was based on a patch from mailing list: When receiving connection, the original wireguard will reset the incoming fwmark (but all the incoming connection info is in kernel sk buffer) then use the 0.0.0.0 as responding source ip, use incoming source ip as dest ip to serching the route from main routing table, this cause the wireguard always use the ip of lowest metric as respoding ip. As above, my patch is trying to save the incoming fwmark or save the incoming dest ip from kernel sk buffer, and then force the wireguard to use them, after a lot of tests (only my use cases), my patch finally working. |
Hi @wackejohn The Patch you have given here is for which wireguard version? Can this patch be applicable for my version? |
Hi, |
Thanks for your info!!. |
Hi, And patch for your wireguard-linux-compat-1.0.20200611 version: |
|
Thanks @wackejohn |
Hi, |
|
Hi @wackejohn |
@dashajyo Yes, from my test result, it's enough. |
|
Thanks for this issue and the patch! I have exactly the same problem! |
Hi, |
|
Hi, |
|
Successfully applied against the 5.4 kernel series. Will test eventually. |
|
您好！感谢你执着和认真推动了开源社区发展，openwrt我也遇到了这个问题第一次给程序打补丁，请问这个补丁代码是放在openwrt目录保存为xxx.patch文件，然后执行命令patch -p1 < xxx.patch，就可以了吗？我看到上面有几个不同的补丁，请问只需要打2022 年 6 月 9 日最新发布的补丁就可以了吗？ |
Hello! Thank you for your dedication and seriousness in promoting the development of the open source community. I also encountered this problem in openwrt. I patched the program for the first time. May I ask if the patch code is placed in the openwrt directory and saved as a xxx.patch file, and then execute the command patch -p1 < xxx .patch, is it ok? I see that there are several different patches above, can I just apply the latest patch released on June 9, 2022?
|
|
|
|
My system environment firmware version OpenWrt 23.05.0-rc1, kernel version 5.15.114, target platform x86/64. After the patch is applied, the data comes in from the vwan0 port and the vwan0 port goes out, but the port of the wireguard changes inexplicably when it goes out. solve |
|
The port of the client will change automatically every time it reconnects to the server |
|
|
|
Thank you Arthur for solving the problem |
Maintainer: @feckert
Environment:
Description:
The tcpdump output:
The output showed that my client(49.94.153.160) connect server (112.3.86.249:5888), but the handshake data was sent from (114.228.200.208). Maybe it's because the wireguard can't bind to specific interface?
The text was updated successfully, but these errors were encountered: