Show HN: An Almost Free, Open Source TURN Server

This has got me reading about TURN and it just seems like a huge ugly hack. Two computers want to send UDP to each other. They are electrically connected by sets of physical cables. They could even be down the street from each other. But they don’t know how to get their routers to set the right bits in their translation tables. Instead it’s just easier to send all their traffic through a third computer in another city thousands of miles away or maybe into outer space and back. Have I got it right?

Yep. But this is what IPv6 was supposed to solve.

I don’t know much about IPv6 but it seems like even if we are stuck with IPv4 we could still make some sort of protocol where my computer could manipulate the NAT table entries allocated to it. Maybe something like DHCP but it deals with ports.

Isn't something like that what UPnP / zeroconf is supposed to do[1][2]?

[1]: https://en.wikipedia.org/wiki/Universal_Plug_and_Play

[2]: https://en.wikipedia.org/wiki/Zero-configuration_networking

Very interesting. I even found some protocols that exactly implement the functionality I was thinking of!

https://en.wikipedia.org/wiki/Internet_Gateway_Device_Protoc...

https://en.wikipedia.org/wiki/Port_Control_Protocol

NAT may go away, but stateful firewalls won't. There will still be many environments where you can't easily get a point to point connection even though the IP is addressable and there is a route.

Won’t the firewall know to let return traffic through if my computer explicitly sends a request first?

From what I understand the real ugly hack is NAT tables thanks to the shortsightedness of IPv4.Everything else flows from there.

Mostly, though, what you are describing is the internet

For me something only qualifies as a 'huge ugly hack' if a better way exists. I think TURN does the best it can in the constraints that exist!

* TURN handles protocol bridging (TCP <-> UDP)

* TURN is useful for privacy preservation.

* TURN handles NAT Traversal (unfortunate when it comes to this)

* TURN is used for security in some cases. It sits at the edge and clients create allocations

Oh I thought TURN was mainly about the NAT traversal. Can you elaborate on the other points? Especially security and privacy?

Even if it is mainly about NAT, how else would you do NAT traversal?

by not having nat?

...only if ipv6 wasn't written by the very people profiting from NAT.

Hole punching: https://en.wikipedia.org/wiki/Hole_punching_(networking)

Oh I guess that’s STUN that does the hole punching.

I’m so used to seeing both STUN and TURN together.

You aren’t completely wrong apparently.

> TURN is considered an extension to the STUN. So, a typical TURN server would include a STUN server implementation by default.

https://www.100ms.live/blog/webrtc-turn-server

STUN is merely a well-thought out signaling protocol. The simplest, and most common, route is for each party to reach out to the rendezvous (STUN server), which then responds with the port and IP in the other peer. Each party then uses the same address and port it received, because remember that a typical NAT merely maps a port to a port on one of its managed/internal endpoints. The mapping that was created for the STUN server is just as good for use by the other peer.

You could do all of that with your own protocol, but...

Some NATs will include the remote IP in the "key" of the mapping, or even more restrictive approaches, meaning that STUN will have to fall back to other strategies and eventually give up and use TURN.

These days you'll also find that mDNS and other local broadcasts play a role, so that the internet can be avoided entirely for LAN peers.

Right, so hole punching alone doesn’t solve the problem of NAT traversal, which is why TURN and things like it are needed.

when I wrote my other comment in my head TURN and STUN were practically synonymous, since I’ve never seen one without the other.

Isn't STUN hole punching? TURN is what you do when STUN fails.

Without TURN, two clients that want to do streaming communication connect directly to each other, letting both ends know things like IP addresses, supported protocols, and other fingerprintable features. This was the norm for a long time - “I got your IP, I know where you live”

I’m not sure what you mean by fingerprinting and supported protocols. None of that would be present inherently in a UDP stream unless the application included it. As for hiding IP address, that is a valid use case for a TURN server but I’m guessing 99% of TURN server usage occurs only because the NAT hole punch failed.

> by fingerprinting and supported protocols. None of that would be present inherently in a UDP stream unless the application included it.

Much like TLS, both clients offer all the protocols, versions, and media encodings that they support so that they can find a common set that they can use together.

This is standard negotiation when establishing connections in WebRTC and it's obviously fingerprintable information.

You’re talking about WebRTC which may or may not make use of a TURN server. And I assume there are other uses of TURN which are completely unrelated to WebRTC.

Use of a TURN server does not imply hiding of negotiation details. The TURN RFC [1] does not mention anything related to media encodings or WebRTC negotiations at all.

[1] https://datatracker.ietf.org/doc/html/rfc5766

Basically. I guess part of the issue is that NAT is also used as a security measure, so there are competing interests in making the ports chosen by outgoing UDP packets deterministic to make STUN easy, versus randomizing and restricting return traffic to the original recipient to make attacking harder and STUN impossible.

> They are electrically connected by sets of physical cables.

Pedantic: Fibre and wireless do not fit this criteria, but I still agree with the spirit.

Extra pedantic: Ethernet cables are galvanically isolated at both ends. There is no electrical connection at all.

That isolation is within the devices, so the devices are still electrically connected, right?

I guess we can say both instances are electromagnetically attached. But then, basically everything is.

99% of this does not depend on Oracle, you can do this on any vm hosting platform you can get. The only point of using Oracle is the price point which will vanish as soon as they can cease using it to build market share. Good to show btw. Nice instructions. They're mostly platform neutral. It might be a different interface to manage on another host of course but the outcome would be much the same.

Thanks, and you're exactly right - the Oracle bit is probably the most basic, interchangeable part of the whole stack. The tricky bit there for me was all the ports/firewall configuration which like you say will be the same/very similar anywhere.

For hobby projects like this I have had no complaints with OCI but yeah, you would have to be crazy to use it in production.

Respect++ for what you said about Peerjs. I used those servers myself for testing when I wrote my own TURN client and always felt a little bad about it. But it saved me tons of time before setting up my own. Now I have my own server (though not as well setup as yours -- your guide is good.)

This is a valuable contribution. IMO, the Internet needs more STUN, TURN, and MQTT servers. It's even more valuable if they support as many protocols as possible and have IPv4 / IPv6. For STUN -- running it with two IPs means it can support bind requests which is necessary for testing NAT types.

Oh, thanks that's very kind of you to say. PeerJS is great - it takes a lot of the complexity out of WebRTC and replaces it with a nice, clean API. I think it was an OK decision for them to use Google for their TURN server - really, the best use case for their cloud server is exactly as you described - get your PoC working, and then if you're serious, implement your own

This how to is extremely comprehensive and well written. You have a knack for writing technical tutorials and documentation that are accessible, clear and simple. Well done!

Good prose, clearly not written by AI - respect!

Cheers :) I trained and worked as a writer in my previous career, so it's nice to know that at least some of those chops remain. Like every other writer on the planet, I've tried AI for generating some base text that I could then tweak, but I find myself spending so much time rewriting that it's quicker just to do it from scratch...

> Additionally, some people have privacy concerns about running their data through anything associated with the big G.

It's important to point out that Web RTC is E2E encrypted, so Google never actually sees your data.

As long as the server you use for signaling is secure, your TURN server may as well be run by the NSA. Since initial signaling is extremely low-bandwidth compared to the actual call, it's usually fine to handle it in your application directly.

THe actual problem with WebRTC is that, in its default setup, every call participant leaks their IP address to everybody else, and you need to upload your data n-1 times for n call participants, making it almost unusable on slow connections. You can mitigate both of these problems with an SFU, essentially a central server that takes in streams from all clients and distributes them further, but then you lose the E2E.

Great write up! It isn’t free, but the price/what it offers is really great with Hetzner. I switched from digital ocean.

Did you evaluate any other TURN servers? I’m curious about your thoughts of the Elixir and Go ones. Maybe even more exist, I haven’t looked recently

oh, no - I am far too lazy to "shop around" for TURN servers and coturn just works and ticks all the open source boxes for me - lots of contributors, recent commits, lots of stars and forks (although these last two aren't as important as the first)

How to doc recommends using Oracle Free Tier but they recently had a breach and leaked login server data https://www.bleepingcomputer.com/news/security/oracle-custom...

Look at Stunner as a Kubernetes friendly alternative to coturn.

https://github.com/l7mp/stunner

For those of you needing turn services without wanting to host, I can highly recommended Xirsys. Excellent service and while pricing is more than Cloudflare you get better network quality.

If you prefer Cloudflare, unless you are using GBs a day you'll most likely have a $0 monthly bill which makes it an excellent choice for small projects and testing.

I'm not paying oracle for cloud services, I learned my lesson the hard way, they're still emailing me about random cloud stuff despite me telling them to stop contacting me.

This codebase seems to be a little old - does anyone have it running as is, or close to as is?

If I was tasked to get this up and running, I would probably start with porting the entire thing to postgres.

Can't we have TURN over something like bittorrent or ifps so that it's decentralized ?

Doesn't bittorrent have the tracker that is acting as the glue to connect to peers?

The problem I see with TURN is there's basically no way to prevent people from abusing it publicly for relaying any traffic they want, without any of your own web sites or WebRTC apps involved.

Basic authentication is covered in Section 11[0]

There are more thoughts on tightening up authentication in the last section "Tightening and tidying"

Apologies if I have misunderstood your comment

[0]https://github.com/lvidgen/WebRTC/blob/master/FOSS_TURN_Serv...

Authentication still requires the client to have access to the password, where you can just take it and use it for any other purpose.

Unless you're asking every user to manually input a TURN password and they promise not to give it out, you're basically forced to reveal it to every visitor of your site.

yes, but you can block cross origin requests to both the credentials server and the PeerJS server which I understand prevents this: "relaying any traffic they want, without any of your own web sites or WebRTC apps involved"

Again, not an expert. This problem only really exists for "ad-hoc" connections where you don't want people to have to set up accounts. coturn has the ability to do standard authentication by checking credentials stored in databases

You can generate short-lived and single-use credentials for users.

Yes, but, if this is a public website that anyone can use, then an abuser using your TURN server for other purposes can also grab a single-use credential from the site, making it a bit pointless.

I see a couple ways to combat that.

* Your TURN server should provide APIs that allow you to verify that allocations/permissions are only created for your users.

* Use an auth mechanism that has an expiry time. Like [0]

[0] https://github.com/pion/turn/tree/master/examples/lt-cred-ge...

> * Your TURN server should provide APIs that allow you to verify that allocations/permissions are only created for your users.

coturn provides these APIs, they're not covered in the writeup, though

> * Use an auth mechanism that has an expiry time. Like [0]

This is how the credentials server in the write up works

Yes, usually some more intelligent auth is needed, depending on your app logic. For example the MRTC SIP-WebRTC gateway will do the usual SIP digest auth first, then will send a temporary TURN password to the WebRTC client + it will allow only the current source IP to use the TURN service (with an extra auth message exchane if the IP changes during the call).