[ameshkov]

We support both H2 and H3 and this is necessary. QUIC is not bad, but there are places where it either does not work at all or works too slow.

And one more thing, even though the code and spec is only published now, we’ve been using TrustTunnel for a long time, started before CONNECT_UDP became a thing.

We’re considering switching to it though (or having an option to use it) just to make the server compatible with more clients.

[eptcyka]

Ah, so you resolve domains before to apply the routes to the profile, I see. As per the spec, network extensions are not allowed to reroute traffic outside the tunnel, destinations set in the tunnel network settings must be routed inside the tunnel. This means that users have to know their domains upfront, the app cannot do this dynamically, if only to comply with apple rules.

[ameshkov]

Actually, no, we don't resolve them. We scan the incoming ClientHello before making a decision on where to route the connections. If the connection should be bypassed we make a connection by ourselves and proxy traffic. Implementing it that way requires having a TCP stack right in the client.

[eptcyka]

Unfortunately, I am no stranger to embedding a whole userspace networking stack into a VPN client either.

[xtacy]

> QUIC is not bad, but there are places where it either does not work at all or works too slow.

Curious: in your experience where does QUIC work bad/slow?

[ameshkov]

For example, in some countries it's either slowed down or outright blocked.