CN, etc.) + a working fix and a request for per-client access management #1387

New issue

Open

opened 2026-10-13 20:41:22 +00:00 by bsakaguchi · 1 comment

bsakaguchi commented

2026-10-13 20:41:22 +00:00

Owner

Originally created by @koster99-blip on GitHub (Aug 24, 2026).
Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3029

Body:

Problem:

Users connecting through mobile carriers in countries with active DPI (Russia, Iran, China, etc.) experience blocking or dropped connections on high UDP ports (30000+). The same users on wired/Wi-Fi connections see no difference between ports - so the issue is tied specifically to the mobile channel, not to the protocol itself.

A fix we found and use:

We worked around this on our own infrastructure by moving the service to port 443/udp instead of the default high port. This fully resolves the connection issue even under the harshest network conditions.

But this fix comes at a cost: it requires manual server configuration (changing the port, along with related firewall/network rule adjustments) - meaning it's out of reach for a typical user, and it removes the main advantage that makes AmneziaVPN valuable in the first place: simple, one-click setup. Right now this fix is only available to those willing to administer a server themselves.

So we'd suggest: make port 443/udp the default (or at least a suggested option with a clear explanation, e.g. "for restrictive networks") right in the setup wizard - so an average user gets a working connection without touching the console.

A second, related issue - access management in a small group:

In practice we've found another gap: the client is clearly designed for a "one person, several of their own devices" scenario, but it's also used to distribute access to a small group of people managed by one administrator. Two things get in the way here:

The name entered in the "New user" field doesn't make it into the vpn:// link itself - the user only sees the server's name/description, not their own profile name.
There's no way to revoke access for a single person - for example, in case of a violation of the hosting provider's terms of use (in the EU jurisdiction this includes requirements to comply with copyright and other legal restrictions). Instead, configs have to be reissued for the entire group. For an administrator who is responsible to the hoster for compliance with these terms, the lack of per-client revocation isn't just an inconvenience - it's a real risk to the whole service.

It would be great to get both of these improvements - along with the simplified default for restrictive networks mentioned above.

We're happy to share more details about our approach to working around the blocking, if that would be useful to the project.

Originally created by @koster99-blip on GitHub (Aug 24, 2026). Original GitHub issue: https://github.com/amnezia-vpn/amnezia-client/issues/3029 Body: Problem: Users connecting through mobile carriers in countries with active DPI (Russia, Iran, China, etc.) experience blocking or dropped connections on high UDP ports (30000+). The same users on wired/Wi-Fi connections see no difference between ports - so the issue is tied specifically to the mobile channel, not to the protocol itself. A fix we found and use: We worked around this on our own infrastructure by moving the service to port 443/udp instead of the default high port. This fully resolves the connection issue even under the harshest network conditions. But this fix comes at a cost: it requires manual server configuration (changing the port, along with related firewall/network rule adjustments) - meaning it's out of reach for a typical user, and it removes the main advantage that makes AmneziaVPN valuable in the first place: simple, one-click setup. Right now this fix is only available to those willing to administer a server themselves. So we'd suggest: make port 443/udp the default (or at least a suggested option with a clear explanation, e.g. "for restrictive networks") right in the setup wizard - so an average user gets a working connection without touching the console. A second, related issue - access management in a small group: In practice we've found another gap: the client is clearly designed for a "one person, several of their own devices" scenario, but it's also used to distribute access to a small group of people managed by one administrator. Two things get in the way here: The name entered in the "New user" field doesn't make it into the vpn:// link itself - the user only sees the server's name/description, not their own profile name. There's no way to revoke access for a single person - for example, in case of a violation of the hosting provider's terms of use (in the EU jurisdiction this includes requirements to comply with copyright and other legal restrictions). Instead, configs have to be reissued for the entire group. For an administrator who is responsible to the hoster for compliance with these terms, the lack of per-client revocation isn't just an inconvenience - it's a real risk to the whole service. It would be great to get both of these improvements - along with the simplified default for restrictive networks mentioned above. We're happy to share more details about our approach to working around the blocking, if that would be useful to the project.

bsakaguchi commented

2026-10-13 20:41:23 +00:00

Author

Owner

@Fish1944 commented on GitHub (Aug 24, 2026):

I have the exact same problem! In St. Petersburg the standard AmneziaVPN instance I run on a rented VPS in the EU works fine on my wired ISP connection, but it doesn’t work on the Tele2 mobile network. I really need a response from the developer - is this something I’m doing wrong, or is it a systemic issue? Thanks!

@Fish1944 commented on GitHub (Aug 24, 2026): I have the exact same problem! In St. Petersburg the standard AmneziaVPN instance I run on a rented VPS in the EU works fine on my wired ISP connection, but it doesn’t work on the Tele2 mobile network. I really need a response from the developer - is this something I’m doing wrong, or is it a systemic issue? Thanks!

bsakaguchi referenced this issue

2026-10-13 21:21:02 +00:00

[PR #1387] [MERGED] bugfix: fixed storeEndpoint parsing #2335