How can one Reality client prevent all others to access the same server?

[Anderhar]

Greetings!

I use xray-core in the form of 3X-UI as server and v2rayA on OpenWRT as client, connected via VLESS Reality.

In this simplest configuration, everything works perfectly for my local network. The problems begin when I try to connect any other Reality client to the same 3X-UI server, either just bypassing v2rayA or even from another network (e.g. cellular). In this case, thе added client (no matter xray or sing-box) always returns "Reality verification failure" while v2rayA is online, and successfully connects as soon as v2rayA stopped.

In other words, v2rayA somehow suppresses all other Reality clients, and the number itself is not the issue (since I've tested simultaneous connection from more than one device, and everything goes fine until v2rayA appears among them).

Perhaps the problem is specific to v2rayA or maybe 3X-UI, but it seems more like it is related to how Reality or xray-core works in principle. It would be nice to have some insight into what might be causing such a strange behaviour.

[Anderhar]

And I'm not the first person to run into this!

[mmmray]

but it seems more like it is related to how Reality or xray-core works in principle

Since you already noticed that you are running into a very rare issue, I suggest that you put this to the test. Eliminate everything you think is not necessary for the problem from your testing setup (panels, weird outbounds on the server, routing rules), and see where you end up.

[Anderhar]

Thanks for the response: any involvement is already a bit encouraging.

In the past few days I continued my tests, and although it's problematic for me to completely avoid any panel, I tried to get a different VPS and install Hiddify instead of 3X-UI with sing-box core instead of xray. But all that changed was the error message text (now it's just "TIME-OUT").
v2rayA doesn't show any troubles when running on my Linux PC instead of OpenWRT router. So finally, I re-installed OpenWRT (no luck) and now can confirm that the problem is in v2rayA version for OpenWRT, or in the OpenWRT itself.

But on the other hand, the very fact that one client can block all others is still a vulnerability of xray-core (and sing-box). Just imagine what happens if one of the affected users, like me, connects to some public or commercial proxy server. Its operation would be paralyzed!
So maybe it can still be considered as a bug, the rare nature of which is disproportionate to its potential harmfulness.

[Anderhar]

If anyone of the developers would like to investigate this case, I can connect to his/her xtls-reality server at arranged hour to demonstrate how things works.

[Anderhar]

Also done (as vulnerability report). But I don't think the config is needed, just because it can be whatever as shown above with Hiddify/sing-box example.

[uuonda]

@Anderhar Has there been a response to your report? I see RPRX replied here but I don't get what he means.

[Anderhar]

Seems to be just picking on words taken out of context, or denying reality maybe. My vulnerability report also goes with no reaction, so apparently no one cares.

Just switched to Homepoxy from v2rayA to move on, but who knows when and how the problem will manifest itself again...

P.S. Binaries for Homeproxy and its dependencies found here.

[mmmray]

Done. The same behavior confirmed.

can you post the config then? to be honest, there is no useful information in this thread or the thread by skywalker to reproduce this issue without v2rayA

clearly REALITY works for a lot of people in multiuser setups, so there has to be something about the config that v2rayA generates that makes it behave this way

[Anderhar]

Things turned out to be simpler: v2rayA indeed has some flaw, but of a different kind, which, multiplied by my oversights, produced all this strange behavior. (Read the explanation below).

Now the vulnerability report is closed and the question is finally answered by RPRX.

[RPRX]

REALITY 请求被导向了它的 SNI 解析出的 IP，而不是你的服务器

[Anderhar]

Seems like you didn't read what is written here, neither SkyWalker1726's issue, nor my vulnerability report, right?

[RPRX]

I mean that Xray has the ability to sniff SNI in TLS Client Hello (and REALITY) then override the IP of the destination, which will block REALITY, and you enabled this ability on v2rayA / 3X-UI. As for "even from another network", it seems impossible.

[Anderhar]

Yes, that's the thing!

First, it looks like v2rayA doesn't provide a setting for "destOverride" at all, or at least in the GUI, yet enforces overriding, leaving the user without a choice. That's why I don't experience the same problem with Homeproxy, where I just unchecked "Override destination" item.

Second, blocking devices from another network is caused by the methodological mistake of mine. Previously, I tested this by sharing internet from my new smartphone, not knowing that it is capable to work as an access point and WiFi receiver simultaneously (my previous phone can't), so it just worked as a repeater for my home network with v2rayA. Today, when you provoked me to redo my experiment (thanks!), I noticed this (actually nice) feature for the first time.

That's the two little oversights that gave me such a horrible picture.

But now I am puzzled by 3X-UI mentioned in your answer. I assume that on the client side, it is best to enable "routeOnly" or disable "destOverride" completely if the first option is not available. But 3X-UI – that's the server side, right? Previously I thought that the default settings are optimal, but now I notice that even the official XRAY-examples pronide varying recommendations regarding Sniffing (1,2), which is a bit confusing. Could you please clarify the best practices for Sniffing configuration on server with respect to Reality?

Actually, my example shows that "destOverride" is a dangerous enough function to be better documented.