connections to own relay addresses?

[robertsdotpm]

Hello, I've been working on a TURN client and I had a question about how Coturn's TCP behaviour is supposed to work?

Let's say that I make an 'allocation' and request a TCP transport. In return I get a new relay address that can be used to send messages to my client. As far as I know: to be able to receive message from this address I then need to create a new permission for a peer. The peer connects to the address and any data they send to it gets routed to me. I think for this you need the exact IP and src port they will use.

While I was testing this out I had the idea of sending a create permission request with the TURN servers listen details. Then I sent a connect request and specified the clients own relay address for the destination. So essentially I told the TURN server to connect to itself on its relay address. This worked and it spat out a new connection ID. From that point on I created a new connection to the TURN server and issued a bind request using the connection ID from before. The server sent out a success code. I then tried to use the connection to see if anything happened.... and I was able to send data and receive it back again.

So the connection diagram probably looks something like this:

1. server -> data con 1 -> servers own relay address
2. client -> data con 2 -> server
3. client -> data con 2 -> server -> data con 1 -> servers own relay addr -> data con 2 -> client

Sorry if this is really obvious: but is this intended behaviour?

[ggarber]

AFAIK There is nothing in coturn preventing a server to send data to himself. In fact this is similar to what happens when you have 2 clients behind a firewall blocking UDP for example. In that case the server is sending traffic to himself.

That specific case you mention could be blocked changing the coturn implementation but I don't see a big issue allowing it. Do you?

Thank you!

[eakraly]

There is nothing in coturn preventing a server to send data to himself.

In this case there is an option to DoS turnserver by creating loop connections to itself? @ggarber

[robertsdotpm]

I thought the self-connect thing was interesting. I had hoped that you could use it as a way to do TCP reverse connections over TURN. E.G. both peers make a TCP con to the relay at the standard port, tell the relay to connect to each other's relay address, and end up with a connection ID that can be used to make a future connection [to the TURN server] a 'data connection.' But you can't do that because apparently Coturn limits connection counts to N per IP address which seems to be something like one. So for this scenario I describe -- it's connecting to itself on the same IP and at minimum both sides would need to do the process. So this wouldn't work for anything practical without a server specifically over-ridding such limits. In the end I went with the standard protocol using UDP for a last resort. UDP has lots of useful properties when it comes to NATs. It's a little easier to work with but does obviously come with drawbacks.