WireGuard outbound: Fix UDP FullCone NAT on Linux#5858
Conversation
LjhAUMEM
commented
Mar 29, 2026
LjhAUMEM
commented
- fix wireguard outbound linux tun fullcone
|
先等 @Kapkap5454 测试看看吧，另外你有没有兴趣研究下 TUN 实现 auto-route 和 auto-redirect #5857 (comment) |
|
|
|
|
|
|
|
|
Tested with my configs from here #5848 (comment) I built new xray from pr, downloaded, replaced, systemctl restart xray on server. Client can't connect with warp on server. This in logs many times. Direct freedom on server - client connects fine. 2026/03/29 09:16:22.513881 [Debug] peer(bmXO…fgyo) - Handshake did not complete after 5 seconds, retrying (try 2) Anyhow, I rebooted both client and server. Client connected successfully. Curl works. Go to https://quic.nginx.org/quic.html. Loads. Start test. Requests sent (gray squares). Then hangs, no green or black squares in test. Wtf. Repeat. Same result. Reload page. Firefox shows this: The connection has timed out. The server at quic.nginx.org is taking too long to respond. Reload many times, tried closing and opening different tab with same site - no result. Test opening different websites in same browser - all ok. Tried opening https://quic.nginx.org/quic.html from my regular pc with different IP - all ok. Went back to client vps, opened private browsing window in firefox, quic test page loads, green squares coming, all ok. Return to regular firefox window, open new tab. Again - The connection has timed out. The server at quic.nginx.org is taking too long to respond. Now, I do remember, during very-very initial tests of xray v26.3.23 on both server and client, from my windows PC with v2rayN and on my android with v2rayng, I ran into the same problem: https://quic.nginx.org/quic.html loading hangs from browser after one or two tries. Then I opened different browser and it loaded. This doesnt seem to happen with xray 26.2.6 on server, I think..... ~09:16 - Client can't connect to internet when server has outbound warp. I attach logs as files, tried to truncate, but still too long. Don't want to omit something possibly important. |
|
The WireGuard TCP connection remains the same before and after this commit; the main difference is with UDP. If you cannot use a TCP connection in WireGuard, then the problem isn't with this commit. In TUN mode, the browser caches the quic.nginx.org IP address obtained from DNS queries, typically prioritizing IPv6. This might mean your outbound IPv6 connection is unstable during the check. Regarding warp, could you try reusing the configurations from |
这么喜欢 sing 包么... |
|
|
|
从 fullcone 那个 commit 到这个 pr 主要改动是 udp 相关，理论上测试 wg 出站的两种 tun udp 没问题和入站的 gvisor tun udp 没问题就行，tcp 连接和以往一样没有任何变动，我这边已经简单测试过都是正常的
|
Maybe you are right. I will run some more tests on the two VPS I made and will report. But I tested on my personal machine with Windows and v2rayN and active server, it looks totally same to 26.2.6. Mosh is working, quic is working. All good. |
|
@Kapkap5454 Please also test the server-side Wireguard outbound usage of gvisor. |
ELI5 please.... "Please also test the server-side Wireguard outbound usage of gvisor." You do mean, test like v2rayN on my Windows PC? which uses gvisor (according to its settings). Correct? I did that, I wrote report in a comment above. |
|
Just to mention, I never updated client with this PR. Only server. If that's important. |
Simply add "noKernelTun": true to your server-side Wireguard outbound configuration.
If your client does not use Wireguard outbound, then keeping the old version is fine.
There's no difference; just make sure your compilation is error-free. |
Probably you are right that there might be a problem with ipv6. I disabled ipv6 address in warp outbound, I also changed "endpoint": "engage.cloudflareclient.com:2408" to static ipv4. And since then I didn't get any problems connecting client to server using this PR. Weird.... "Please also test the server-side Wireguard outbound usage of gvisor." 2026/03/29 16:48:05.705696 [Info] switching dialer I do ocasionally get this in logs Seems like can be merged. Thank you so much! |
|
Thanks for testing. I'm glad to see that NoKernelTun is working correctly. If Linux tun behaves any differently from NoKernelTun, feel free to provide feedback. I'm also glad you understand that this PR is for fixing UDP. If you encounter other issues, please open a separate issue.
I encountered this when using xhttp too, but it didn't seem to affect the connection, and I didn't modify anything related to xhttp, so... |
|
Some new changes? Yesterday I put artifact from this pr on my main proxy server. The one I connect to with v2rayN+singbox TUN from windows. Then I switched and tried maybe 50 times in different browsers, changing from this pr to 26.2.26 and backwards and again and again.... many-many times. WIth occasional hangs. I can't get consistent results to say "do this and this and get this behaviour", I see nothing interesting in logs except for stream canceled, nothing interesting in wireshark. From a very dumb user perspective ignoring the mechanics and technical details. It's like it overfloods something with udp/quic, probably for some time switches to tcp, then dies... I don't know how it's possible, sorry 😅. The most consistent results I can get is only with ms edge browser, which I have configured most closely to default settings and without built in DOH. Today I woke up, opened MS Edge, run 2-3 tests (all ok, with QUIC). Then it started running these tests with black squares only (meaning it could only achieve regular http, not quic). So, like downgraded. Ran for 2 times this way. Then hung again. Internet explorer showing This page isn’t working right now quic.nginx.org didn’t send any data. ERR_EMPTY_RESPONSE. Closing browser doesn't help. It continues working in other browsers after this. As I said, it does hang sometimes in other browsers as well. But in ms edge I can get to this hung up state the fastest way. I wish I could give you more details. Should I try this PR now, after some changes mentioning buffer were made? I also think, that in 26.2.6, it always loads these squares sequentially: from left to right, first request sent (gray squares), then they start appear green from left to right, top to bottom. On 26.3 and after, I notice it can start getting green squares in the middle of the section, before earlier appeared. |
|
And just to remind you, something similar happened yesterday on two test VPS I made, which used only raw xray, with xray tun on the client side.... |
|
It definitely instantly unfroze in MS Edge after I switched to direct-freedom. |
|
I think you should know that the modifications involved only relate to whether you are using Wireguard for outbound traffic. If you are using other outbound methods and encounter problems, you shouldn't be complaining here. Now tell me, which outbound Wireguard configuration is causing your dissatisfaction: Linux tun or Gvisor tun? |
|
According to 5845, have you tried other protocols? |
Well, I do use wireguard outbound for cloudflare warp on the server, right? That is the case for this PR? We already solved some major problems with it here. QUIC and Mosh started to work on the client after it. Linux tun or Gvisor tun: I experienced something similar yesterday, when I used two fresh test VPS, with raw xray. It was Linux-tun. Now, as far as I understand, I am using gvisor tun. Because on the server, I have one more wireguard inbound. Its dormant, I dont use it, but its there. And logs say, kernel-tun not supported for wireguard inbound, switching to gvisor tun. So it means it also affects wireguard-warp outbound on the server, am I correct....? So I experience this problem on both: linux tun and gvisor tun. Right now I tested again. MS Edge froze on quic test page. I changed to freedom outbound on the server (without disabling the wireguard-warp outbound). It immediately unfroze quic test page. I switched back to warp. Quic page continues to work. I pressed run test 5-8 times. All QUIC results. Tried incomplete tests (click run, then cancel. then again run). Working. Turned Xray off on the client. Turned on. If you think this is some different kind of issue, ok I will stop writing here. Unfortunately I doubt this would qualify for a separate issue, rprx will close it. Not enough data =/ |
You mean this? No, I haven't... Should I? Try VLESS + ENC? The problem seems to be connected with wireguard outbound, I don't understand how that might help. But if you insist, I can test. |
|
let's start over. I need you to provide your server-side configuration file, and whether curl works correctly when the problem occurs. Server-side update: https://github.com/XTLS/Xray-core/actions/runs/23727523363/artifacts/6171013326 |
|
Perhaps I should provide you with a version of Wireguard that only restores the old version for testing? If it works immediately after switching to Freedom, it doesn't necessarily mean it's a Wireguard issue, because you're using a warp, another Wireguard service provider. If possible, it would be best to host your own Wireguard inbound service and Freedom outbound service; that would be ideal. |
|
It is very hard to reproduce consistently. I will try to find some pattern before giving full config and logs.... Right now my observation is: |
|
No, I totally can't reproduce it consistently. It has been working absolutely perfect for the last hour, done hundreds of tests.... I withdraw all these complaints from here. If it ever happens I will open a new issue and provide dump. Thank you for your time. |
|
I understand your confusion. The only difference between the new and old versions of Wireguard outbound is the use of I think the only explanation is that the warp in your region is unstable. You can try modifying the address created by |
|
Additionally, if you suspect a problem with an inbound or outbound service, please provide a reproducible configuration. Ideally, the inbound service should be hosted by self, as this will facilitate troubleshooting. |
RPRX
changed the title
4 participants
