Suspicious UDP rebind leads to disconnect in udp traversals

[Clockware]

Hi. As a start, I'll shortly say that I was looking for a portable, fully functioning, precompiled for many platforms, SOCKS5 Server, and this one caught my attention and was the best in my testing so far.

However, I'm here to report the bug (or so I think). One of the tests I perform to test UDP proxies is playing games that utilize UDP protocols (legacy Blizzard games mostly), it's great test to see how "transparent" proxy really is.
The first main test was: VPS hosting hev-socks5, me connecting from Windows 11 through proxifier-analog to the VPS address. I got disconnected after 6 minutes in the game.

I started narrowing issue down:

1. I moved hev-socks5 from VPS to my router
2. I changed proxifiers, as well as utilizing SOCKS5 global on OS to avoid any proxifier issues

But the issue remained, and very clearly detectable from Info logs of the server. Typical disconnect looks like this:

[2024-08-04 14:45:03] [I] 0x7fc6762b4a30 socks5 server tcp [137.xx.105.xx]:443
[2024-08-04 14:45:04] [I] 0x7fc6762b4ad0 socks5 server tcp [37.xx.28.yy]:80
[2024-08-04 14:45:04] [I] 0x7fc6762b4ad0 socks5 server tcp [66.xx.185.yy]:3724
[2024-08-04 14:45:05] [I] 0x7fc6762b4b70 socks5 server tcp [66.xx.185.yy]:3724
[2024-08-04 14:45:05] [I] 0x7fc6762b4e20 socks5 server tcp [66.xx.185.yy]:3724
[2024-08-04 14:47:10] [I] 0x7fc6762b4a30 socks5 server tcp [137.xx.105.yy]:443
[2024-08-04 14:47:10] [I] 0x7fc6762b4b70 socks5 server tcp [37.xx.28.yy]:80
[2024-08-04 14:47:10] [I] 0x7fc6762b4ad0 socks5 server tcp [66.xx.185.yy]:3724
[2024-08-04 14:47:11] [I] 0x7fc6762b4e20 socks5 server tcp [66.xx.185.yy]:3724
[2024-08-04 14:47:11] [I] 0x7fc6762b4ec0 socks5 server tcp [66.xx.185.yy]:3724
[2024-08-04 14:47:18] [I] 0x7fc6762b4a30 socks5 server tcp [37.xx.16.yy]:1119
[2024-08-04 14:47:20] [I] 0x7fc6762b4b70 socks5 server tcp [137.xx.105.yy]:443
[2024-08-04 14:47:23] [I] 0x7fc6762b4ad0 socks5 server tcp [37.xx.28.yy]:443
[2024-08-04 14:47:25] [I] 0x7fc6762b4e20 socks5 server udp [0.0.0.0]:0
[2024-08-04 14:47:26] [I] 0x7fc6762b4f60 socks5 server tcp [34.xx.41.yy]:443
[2024-08-04 14:47:27] [I] 0x7fc6762b0a20 socks5 server tcp [52.xx.127.yy]:443
[2024-08-04 14:47:46] [I] 0x7fc6762b0ac0 socks5 server tcp [137.xx.105.yy]:443
[2024-08-04 14:48:26] [I] 0x7fc6762b0b60 socks5 server tcp [34.xx.78.yy]:443
[2024-08-04 14:48:27] [I] 0x7fc6762b0e00 socks5 server tcp [34.xx.172.yy]:443
[2024-08-04 14:48:41] [I] 0x7fc6762b0ac0 socks5 server tcp [137.xx.105.yy]:443
[2024-08-04 14:48:51] [I] 0x7fc6762b4f60 socks5 server tcp [34.xx.41.yy]:443
[2024-08-04 14:48:52] [I] 0x7fc6762b4a30 socks5 server tcp [52.xx.127.yy]:443
[2024-08-04 14:49:00] [I] 0x7fc6762b0b60 socks5 server tcp [34.xx.78.yy]:443
[2024-08-04 14:49:01] [I] 0x7fc6762b0ea0 socks5 server tcp [34.xx.172.yy]:443
[2024-08-04 14:50:38] [I] 0x7fc6762b0b60 io timeout
[2024-08-04 14:50:43] [I] 0x7fc6762b0ea0 io timeout
[2024-08-04 14:50:43] [I] 0x7fc6762b0ac0 io timeout
[2024-08-04 14:50:49] [I] 0x7fc6762b4b70 io timeout
[2024-08-04 14:51:10] [I] 0x7fc6762b4a30 socks5 server tcp [137.xx.105.xx]:443
[2024-08-04 14:51:11] [I] 0x7fc6762b4ec0 socks5 server tcp [137.xx.105.xx]:443
[2024-08-04 14:52:12] [I] 0x7fc6762b4ec0 io timeout
[2024-08-04 14:53:11] [I] 0x7fc6762b4a30 io timeout
[2024-08-04 14:57:11] [I] 0x7fc6762b0ea0 socks5 server tcp [137.xx.104.yy]:443
[2024-08-04 14:58:12] [I] 0x7fc6762b0ea0 io timeout
[2024-08-04 15:02:11] [I] 0x7fc6762b4f60 socks5 server tcp [137.xx.104.yy]:443
[THIS IS WHERE DISCONNECT HAPPENS] [2024-08-04 15:02:25] [I] 0x7fc6762b0f40 socks5 server udp [0.0.0.0]:0
[2024-08-04 15:03:25] [I] 0x7fc6762b4e20 io timeout
[2024-08-04 15:03:35] [I] 0x7fc6762b4f60 io timeout
[2024-08-04 15:03:41] [I] 0x7fc6762b4b70 socks5 server tcp [172.xx.17.yy]:443
[2024-08-04 15:03:45] [I] 0x7fc6762b0ea0 socks5 server tcp [137.xx.104.yy]:443
[2024-08-04 15:03:45] [I] 0x7fc6762b0b60 socks5 server tcp [18.xx.24.yy]:443
[2024-08-04 15:03:45] [I] 0x7fc676183040 socks5 server tcp [137.xx.104.yy]:443
[2024-08-04 15:03:46] [I] 0x7fc6762b4f60 socks5 server tcp [18.xx.91.yy]:443

It's the full log using "info". I have others but this is the shortest one, only 6 minutes from udp binds.

I really liked the project and decided to report it in case the owner fixes it faster than I'll do SOCKS5 by myself :) There are so many socks5 projects yet not so many of them are portable and high quality.

I can only say that everything works correctly without the SOCKS5, and I also got positive results from using ShadowSocks (although it's not quite socks5), however I'm interested in SOCKS5 specifically right now because of more flexible clients.

[heiher]

If there is no data transmission in both directions of TCP and UDP for more than the configured timeout (read-write-timeout), the session will be closed. The default value of read-write-timeout is 60 seconds, try to increase it?

[Clockware]

If there is no data transmission in both directions of TCP and UDP for more than the configured timeout (read-write-timeout), the session will be closed. The default value of read-write-timeout is 60 seconds, try to increase it?

I can do that, yes (saw the setting). But there is certain level of distrust for this solution long-term, and here's why:

• Disconnects happen randomly, and usually far more than 60 seconds (3 minutes, 6 minutes, 9 minutes, 20 minutes), 60 seconds is indeed the current default
• There are UDP transmissions for sure, it's a game. For several players, the exchange should be around 30 packets/sec, UDP-only

Which is why I have a strong sense that UDP death might be tied to the death of something that is non-UDP related (thread, associate TCP connection, some other TCP connection, etc). And if I increase timeout for 2 hours, it'll just mean that I get the same effects but after 2 hours (somewhat harder to replicate, I don't play that long, but never impossible), because the timeout doesn't actually care for UDP.

Makes by UDP connection rely on a happy thread.
What you suggest will indeed help me locally, but this still has to be reported.

[Clockware]

RFC1928:

A UDP association terminates when the TCP connection that the UDP
ASSOCIATE request arrived on terminates.

If that's why connection terminates, I guess what I'm seeking is not RFC compliant socks5 server. I need UDP connection to stay if there are packets to relay. I can't force all socks5 clients and proxifiers in the world to keep that tcp connection even if it's their fault.

[heiher]

@Clockware Perhaps I have identified the root cause of this issue. Could you please verify it? I look forward to your feedback.

Prebuilt artifacts: https://github.com/heiher/hev-socks5-server/actions/runs/12610970806