Opened 2 years ago

Last modified 4 months ago

#25596 new defect

Configure TURN servers for the proxy and/or client

Reported by: arlolra Owned by:
Priority: Medium Milestone:
Component: Circumvention/Snowflake Version:
Severity: Normal Keywords:
Cc: dcf, arlolra Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


This may require spinning up our own TURN servers somewhere.

In most cases, the public ip candidates given by STUN servers are sufficient for peers to negotiate a working p2p path. But sometimes, maybe 14% of the time [1], this isn't enough -- usually due to symmetric NAT / lack of port preservation, and a TURN relay is required as a last resort.

Also, once snowflake proxies & clients are multiplexed, perhaps the likelihood that TURN continuous to be absolutely required for every pair of peers greatly decreases and we might be fine again. More thought is needed here.

Migrated from

Child Tickets

Change History (1)

comment:1 Changed 4 months ago by cohosh

I mentioned this a bit in #33666. It looks like we've got quite a few proxies and clients behind more restrictive NAT topologies.

I have some doubts about the usefulness of this solution in a censorship circumvention setting. If we run our own TURN servers, they could be blocked by a censor. Basically, it's a similar problem that we're having with STUN, but since all traffic is also proxies through the TURN servers, we're relying on them more heavily. We can't just make a domain-fronted connection to the TURN server which we might be able to do for STUN.

Still, it might be a short term solution for clients behind symmetric NATs while we figure out how to do something smarter with matching clients to proxies that will work for them.

Note: See TracTickets for help on using tickets.