UDP fallback somewhat broken in 5.1.0+?

[terrytw]

Describe the bug
As someone already mentioned: #2555
I did a little test, it seems to be related to UDP fallback.

Adguard has a function which allows user to name a socks5 proxy as upstream proxy. It also supports UDP over socks5.
So what people do is that they use adguard in VPN mode, and shadowsocks in transparent mode, and in adguard, set 127.0.0.1:1080 as upstream socks5 proxy, and tick "UDP over socks5" if UDP relay is supported by server and UDP fallback is enabled by shadowsocks client together with SIP003 plugin. Everything was working as intended up until 5.0.6.

From 5.1.0, something seems to be broken. With the same aforementioned setup, Adguard gave a "UDP over socks5 not supported by this proxy" error message, with UDP fallback enabled. However if you disable UDP fallback and SIP003 plugin, then the error message goes away. I think it performs a connectivity test upon connection, and the result suggests UDP over socks5 is unreachable, when UDP fallback is enabled.

So I suspect something is wrong is the UDP fallback function. Oddly though, when I tested UDP relay in VPN mode, it seems to be working. But I don't know how to test the socks5 proxy.

[terrytw]

I just did some test again. In 5.1.0 which is the first version where you guys switched to shadowsocks-rust, with SIP003 plugin enabled and UDP fallback disabled, everything works, but if I enable UDP fallback, then error occurs. The same could not be said for 5.1.2, which is expected since fbffc98 was introduced in 5.1.2.

But I think it further proves that UDP fallback is broken, since UDP over socks5 proxy works for 5.1.0 (presumably 5.1.1 too).

[Mygod]

Just tested UDP fallback + plugin working as intended. The change you mentioned shouldn't be relevant as you are always either using both UDP fallback + plugin or neither. Did you test v5.1.1 too?

[terrytw]

5.1.1 behaves similarly to 5.1.0.

In summary, in versions 5.1.0, 5.1.1, 5.1.2, with UDP fallback enabled, in proxy mode, Adguard's UDP over socks5 connectivity check fails. Whereas in 5.0.6, same check passes, and same check passes in 5.1.0, 5.1.1, 5.1.2, if UDP fallback is disabled.

Can you please tell me how you tested UDP relay with socks5 proxy? If I can confirm that socks5 proxy works, maybe it's adguard's connectivity check that's at fault, and I can open an issue over there.

[Mygod]

There is no difference in UDP relay between different modes. I think it's due to Adguard. Please update this issue if there is any new progress.

[sfionov]

@Mygod

Hello! I'm AdGuard developer.

I investigated issue.
Not an UDP fallback broken actually after moving to shadowsocks-rust, but UDP relay is not enabled and there is no way to enable it from UI.

After I added

        config.put("mode", "tcp_and_udp")

to line 110 of com.github.shadowsocks.bg.ProxyInstance

It was fixed, and UDP relay if up and working, and can use it with AdGuard outbound proxy functionality. Otherwise, AdGuard receives "command not supported" in reply to "UDP ASSOCIATE" command.

ShadowSocks 5.0.6 has been passing this parameter to shadowsocks-libev's ss-local, but ShadowSocks 5.1 doesn't do it now :(

[Mygod]

@sfionov It should be enabled via here:

shadowsocks-android/core/src/main/java/com/github/shadowsocks/bg/BaseService.kt

Line 249 in 70d509e

if (udpFallback == null && data.proxy?.plugin == null) "-U" else null)

Make sure you have disabled plugin?

[sfionov]

@Mygod

I investigated complaints from users which use v2ray-plugin, that UDP doesn't work. Without plugin, it works. And with plugin it works too when I enable UDP.

Is it expected behaviour to disable UDP relay when plugin is enabled? Some users used this configuration successfully on SS 5.0.x.

[Mygod]

Intended behavior. UDP should be turned off with plugins to evade traffic analysis. To use it you need to use UDP fallback.

[sfionov]

But this configuration is not full replacement. UDP fallback configuration is listening only on UDP port for packets with UDP SOCKS5 header, but SOCKS5 protocol also requires established TCP SOCKS5 connection with udp association, before sending packets to that association.

May be sslocal may have a mode "tcp in this process, but also reply to udp associate with this host:port" ?

[Mygod]

First of all, UDP ASSOCIATE command is not supported by Shadowsocks (again to evade traffic analysis). The server is supposed to time out UDP connections just like a NAT UDP server.

If you are talking about running concurrent TCP/UDP connections, I think if you run the UDP profile on the same server, you should not encounter any issue.

[sfionov]

First of all, UDP ASSOCIATE command is not supported by Shadowsocks (again to evade traffic analysis).

Yes, in ShadowSocks case it is not real association. But SOCKS5 protocol requires that this command is called before UDP packets are sent. -u mode supports this command and just returns configured UDP relay address instead of temporary associated address:
https://github.com/shadowsocks/shadowsocks-rust/blob/a27c3902e09618d3841feeacc9f432083f128ca0/src/relay/tcprelay/socks5_local.rs#L201
So, any SOCKS5-with-UDP client will operate correctly with -u, despite the fact that association is not real.

But in -U mode, UDP ASSOCIATE is not provided, thus it reduces number of SOCKS5-with-UDP clients that support this scheme.

I suggest to add another flag (e.g. --udp-fallback-client-addr=localhost:1080) to enable logic from tcprelay/socks5_local.rs but without actually enabling UDP - just returning address of UDP fallback in reply to UDP ASSOCIATE. This will turn on proper SOCKS5 UDP initialization from SOCKS5 client's view but traffic will be sent to UDP fallback listen port.

[Mygod]

Are you saying you want a fake UDP ASSOC support from sslocal? Since there is no way of keeping the association alive, I think we can just open a fake UDP ASSOC TCP connection? CC @madeye @zonyitoo

[sfionov]

I want a fake UDP ASSOC working in UDP fallback mode just as it works in -u mode. It will be good if "main" tcp-only sslocal will be able to return fake UDP ASSOC to "udp fallback" sslocal, allowing more SOCKS-with-UDP clients to properly use this configuration.

My only concern in this scheme is that misconfiguration may reduce security - one sslocal directs client to "some address" which may not be another sslocal.

[zonyitoo]

I am not quite getting the point of "fake UDP ASSOC". Please make sure that I understand this correctly: "fake UDP ASSOC" is to return an address (specified by --udp-fallback-client-addr) from TCP command "UDP_ASSOCIATE".

It seems that this is related to a "udp fallback" mode, what is "udp fallback"?

[Mygod]

@zonyitoo I think the point is to support UDP ASSOCATION command in TCP client blindly (i.e. not creating the actual UDP association).

[zonyitoo]

It can be achieved by removing these lines: https://github.com/shadowsocks/shadowsocks-rust/blob/988e69d4dab676df9a61daf692765c353f5eb6f9/src/relay/tcprelay/socks5_local.rs#L208-L214 .

But is that really a good solution? :(

[Mygod]

I think it is a good remedy since we are not doing anything with the connection anyways.

[Mygod]

Alternatively, maybe we can add an option so that the user can choose to enable this function?

[zonyitoo]

I think it is a good remedy since we are not doing anything with the connection anyways.

Well, if a socks5 server doesn't support a command, it should always return CommandNotSupported to client. Is there another way?

[zonyitoo]

Since there is no way around, I have added a command line option for sslocal

sslocal --udp-bind-addr 127.0.0.1:1111

It will reply with this address no matter UDP association is enabled or not.

[terrytw]

Since shadowsocks-rust has added the function to create fake UDP association, and shadowsocks-android has updated underlying shadowsocks-rust, can devs please add the UI option to enable this function? Many thanks! @Mygod

[Mygod]

Reopening this for visibility (i.e. so that I do not forget).

[JhonHuGit]

@terrytw Sorry to bother, but I have encountered this problem as you were. I can see that devs changed something but I don`t know how to use it.
I am now using shadowsocks 5.1.7 in proxy only mode and adguard 3.6 vpn mode. But it cannot work. Could you help me with it?

[terrytw]

@JhonHuGit This issue has been fixed by the devs in 5.1.7. No user configuration needed. I am not having problem with it anymore.

Try your setup in 5.0.6 first, if it does not work, then your problem is unrelated with this issue, you need to double check if your setup is correct.

[JhonHuGit]

@terrytw Version 5.0.6 works perfectly. Once upgraded to 5.1.3 or above, I can't connect to Google.com. Strangly, websites that are not blocked by gfw, such as gamersky.com can be connected without ads.
I am now setting shadowsocks in proxy only mode without plugins, and adguard in VPN mode with socks5 proxy(127.0.0.1:1080, udp via socks5 unchecked). Is this configuration correct?

[terrytw]

@JhonHuGit If you have

udp via socks5 unchecked

Then your problem is completely unrelated to this particular issue I opened, my issue is solely about udp over socks5.

I would suggest you look somewhere else, if it works for you in 5.1.2, but not 5.1.3, you should look into the changes that had been made between those 2 versions. Change your settings, try every version starting from 5.1.0, find out what works and what does not. If you have identified a new problem, maybe open a new issue about it.

I am now setting shadowsocks in proxy only mode without plugins, and adguard in VPN mode with socks5 proxy(127.0.0.1:1080, udp via socks5 unchecked)

From the limited info you have provided, there is no problem with this setting, just don't forget to point your DNS resolver to the shadowsocks port. (On a second thought, you said it worked for you in 5.0.6, so you must have the DNS settings right)

In 5.1.0, shadowsocks-android switched underlying program from shadowsocks-libev to shadowsocks-rust, which led to numerous changes, along with some bugs that have been gradually fixed. Some old features like DNS over UDP were dropped, which could've caused problems for some. My point is that it is difficult to pinpoint out what exactly is the problem for you, since there are so many things that were changed.

[JhonHuGit]

@terrytw I have set my dns server to 127.0.0.1:5450 in adguard and it works! Thank you!