coturn setup - ports required

[Christopher Herbert]

I am in the process of setting up a coturn server. Habitually I run ufw and close off all but the essential stuff.

I was going back over the instructions for this and saw a reference to needing all UDP and TCP ports open, is that correct - everything?

I currently have port 22 locked down to a specific IP address, user etc, do I need to completely open that and do ALL ports really need to be open on both UDP and TCP?

This is probably a stupid Q, and I am sure I have missed something that answers it, but I'd be grateful (yet again) for your patience.

[Calvin Walton]

For coturn to work correctly, you need to allow incoming connections on the configured STUN/TURN ports. With the configuration we recommend, the minimum is 443, 444, 3478, 3479 for both TCP and UDP.

However, coturn *also* has to set up a 2-way UDP connection with the other end (your BigBlueButton server). In theory this should work as long as outgoing UDP packets are allowed and the firewall does connection tracking... but it may be more reliable if you allow the entire range of UDP ports.

Calvin.

[Christopher Herbert]

By the 'entire range' do you mean the ports as specified in the UDP port range for BBB (ie UDP ports in the range 16384 - 32768) incoming and outgoing or ALL ports (ie effectively no firewall).

[Calvin Walton]

It should just require the UDP port range as configured in coturn's
turnserver.conf (we recommend using the same port range as
BigBlueButton for that).

Calvin.

> --
> You received this message because you are subscribed to a topic in the Google Groups "BigBlueButton-Setup" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/bigbluebutton-setup/7k6SJtofqLE/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to bigbluebutton-s...@googlegroups.com.
> To post to this group, send email to bigbluebu...@googlegroups.com.
> Visit this group at https://groups.google.com/group/bigbluebutton-setup.
> To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-setup/a3dc8641-e97a-4f7e-80e4-b09b3d4057d7%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Christopher Herbert]

Thanks, I expected that answer, but past experience taught me not to assume and be litteral, so sorry if I seem to be asking stupid Qs.

I have one more ...

In the coturn instructions it says "Replace <random value> to a random value for a shared secret (instructions for generating a new secret are in a comment in the file)." At this point I become confused again.

The config file incl;udes the following ...

# TURN REST API flag.
# Flag that sets a special authorization option that is based upon authentication secret.
# This feature can be used with the long-term authentication mechanism, only.
# This feature purpose is to support "TURN Server REST API", see
# "TURN REST API" link in the project's page
# https://github.com/coturn/coturn/
#
# This option is used with timestamp:
#
# usercombo -> "timestamp:userid"
# turn user -> usercombo
# turn password -> base64(hmac(secret key, usercombo))
#
# This allows TURN credentials to be accounted for a specific user id.
# If you don't have a suitable id, the timestamp alone can be used.
# This option is just turning on secret-based authentication.
# The actual value of the secret is defined either by option static-auth-secret,
# or can be found in the turn_secret table in the database (see below).
#
#use-auth-secret

# 'Static' authentication secret value (a string) for TURN REST API only.
# If not set, then the turn server
# will try to use the 'dynamic' value in turn_secret table
# in user database (if present). The database-stored  value can be changed on-the-fly
# by a separate program, so this is why that other mode is 'dynamic'.
#
#static-auth-secret=north

The sample code has the lines ...

use-auth-secret
static-auth-secret=<random value>
which I take to be the same commented out lines as above with <random value> = north

This just looks like a simple string, so what is the references to

# This option is used with timestamp:
# 
# usercombo -> "timestamp:userid"
# turn user -> usercombo
# turn password -> base64(hmac(secret key, usercombo))

all about and why does the guide say "(instructions for generating a new secret are in a comment in the file)" because I don't really get 
what the whole timestamp references are suggesting we actually do in creating the secret or what the format is ... it all seems 
contradictory.

I know I am probably being very dim, but I am confused ...

Thanks you so much for all your help.

On Monday, June 17, 2019 at 6:50:04 PM UTC+1, Calvin Walton wrote:

It should just require the UDP port range as configured in coturn's
turnserver.conf (we recommend using the same port range as
BigBlueButton for that).

Calvin.

On Mon, 17 Jun 2019 at 13:28, Christopher Herbert <secur...@gmail.com> wrote:
>
> By the 'entire range' do you mean the ports as specified in the UDP port range for BBB (ie UDP ports in the range 16384 - 32768) incoming and outgoing or ALL ports (ie effectively no firewall).
>
> On Monday, June 17, 2019 at 5:16:37 PM UTC+1, Calvin Walton wrote:
>>
>> For coturn to work correctly, you need to allow incoming connections on the configured STUN/TURN ports. With the configuration we recommend, the minimum is 443, 444, 3478, 3479 for both TCP and UDP.
>>
>> However, coturn *also* has to set up a 2-way UDP connection with the other end (your BigBlueButton server). In theory this should work as long as outgoing UDP packets are allowed and the firewall does connection tracking... but it may be more reliable if you allow the entire range of UDP ports.
>>
>> Calvin.
>>
>>
>> On Monday, 17 June 2019 09:20:49 UTC-4, Christopher Herbert wrote:
>>>
>>> I am in the process of setting up a coturn server. Habitually I run ufw and close off all but the essential stuff.
>>>
>>> I was going back over the instructions for this and saw a reference to needing all UDP and TCP ports open, is that correct - everything?
>>>
>>> I currently have port 22 locked down to a specific IP address, user etc, do I need to completely open that and do ALL ports really need to be open on both UDP and TCP?
>>>
>>> This is probably a stupid Q, and I am sure I have missed something that answers it, but I'd be grateful (yet again) for your patience.
>
> --
> You received this message because you are subscribed to a topic in the Google Groups "BigBlueButton-Setup" group.
> To unsubscribe from this topic, visit https://groups.google.com/d/topic/bigbluebutton-setup/7k6SJtofqLE/unsubscribe.

> To unsubscribe from this group and all its topics, send an email to bigbluebutton-setup+unsub...@googlegroups.com.

[Christopher Herbert]

Oh, I nearly forgot, what if any limit exists on the secret's length (assuming it is just a random text string)?

[Chad Pilkey]

The timestamp and turn user and password is a different authentication type and isn't relevant to how we suggest setting up the TURN server. You want to take the example configuration on our site and replace what the default is. You can create a backup of what is there by default for reference, but everything that is needed is in our example configuration.

You want your static-auth-secret to be long enough that it can't be guessed and it should be randomly generated. The example configuration recommends using "openssl rand -hex 16" to generate a string, but you could use any method you want.

[Christopher Herbert]

OK, I did that in anticipation of that being the case figuring I could easily backtrack if I needed to.

Which brings me to a curious issue.

This morning I could connect and do everything fine both within my local lan and if I connected via the mobile network. After I configured the coturn I can no longer access it via the mobile network but lan is still fine.

I have worked through all of this prior to setting up the coturn then revisited it to check if anything needed adjusting but can't see anything. I get 1007 errors when I try to connect the audio and 1020 errors with the camera. I assume these are coturn related? Anything else you suggest I check again very carefully?

[Calvin Walton]

You skipped over part of the sample file in the documentation...

On Mon, 17 Jun 2019 at 15:48, Christopher Herbert <secur...@gmail.com> wrote:
> In the coturn instructions it says "Replace <random value> to a random value for a shared secret (instructions for generating a new secret are in a comment in the file)." At this point I become confused again.
>

> The sample code has the lines ...
>
> use-auth-secret
> static-auth-secret=<random value>
> which I take to be the same commented out lines as above with <random value> = north

Right above that it has this comment:

# Configure coturn to use the "TURN REST API" method for validating time-
# limited credentials. BigBlueButton will generate credentials in this
# format. Note that the static-auth-secret value specified here must match
# the configuration in BigBlueButton's turn-stun-servers.xml
# You can generate a new random value by running the command:
# openssl rand -hex 16

which does give a method for generating a random string.

[Christopher Herbert]

I somehow missed the connection of the last two lines ... its obvious now I see it. I did read it but took it as 2 different points, not sure why ... must be tired ...

[Chad Pilkey]

Just to confirm, you're getting 1007 errors when trying to connect to audio from your mobile network? A 1007 is an ICE Negotiation error and that means that the browser and the server couldn't find a pair of IPs and ports to connect to each other. In the recommended setup the server will be sending its public IP for its candidate and then all the 16k UDP ports get forwarded to the BBB server everything works coming in. The TURN server should only be needed if the client's network has UDP restrictions in place.

[Christopher Herbert]

Yes ... it is perplexing me. I have not changed any firewall settings, and the mobile connections were working before. Its only since I started trying to get the TURN server working that it has all gone awry.

When I use https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ to test the TURN server I am not getting any suffixes at all - but I am getting the internal IP addresses returned in the test ... I was expecting external addresses to be returned, correct?

I think I must have some config error(s) somewhere ... but is it BBB, kurento SIP or TURN

I am also getting this error when I restart BBB

** Potential problems described below **
..........................
# Warning: The setting of xx.xx.xx.xx for proxy_pass in
#
#    /etc/bigbluebutton/nginx/sip.nginx
#
# does not match the local IP address (172.16.1.55).
# (This is OK if you've manually changed the values)

Is that significant in this context?

[Chad Pilkey]

That trickle ICE test is the client's candidates and wouldn't actually show the issue for your case. You need to know what the candidate the server is sending. Try connecting from a non-mobile device and check the browser log for the SDPs. The remote SDP will have exactly one candidate and that will be the candidate that the server is sending. The IP for that needs to match the public IP of your server.

[Fred Dixon]

Hi Christopher,

> # Warning: The setting of xx.xx.xx.xx for proxy_pass in

You want that IP address to match the IP address of where FreeSWITCH is listening for incoming SIP calls.  

For example, if the setting is 159.203.18.197:7443, then you want to be able to do

  sudo netstat -antp | grep 159.203.18.197:7443

and see

tcp        0      0 159.203.18.197:7443     0.0.0.0:*               LISTEN      5032/freeswitch 

which confirms FreeSWITCH is listening on that port ready to accept an incoming call,.

Regards,... ?Fred

--
You received this message because you are subscribed to the Google Groups "BigBlueButton-Setup" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-s...@googlegroups.com.

To post to this group, send email to bigbluebu...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-setup.

To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-setup/739bf8c1-ab1e-4ebd-aad4-cdad8dbcd403%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

BigBlueButton Developer

http://bigbluebutton.org/

@bigbluebutton

[Chad Pilkey]

If FS wasn't listening on 7443 the client would show a 1002 websocket error.

To unsubscribe from this group and stop receiving emails from it, send an email to bigbluebutton-setup+unsub...@googlegroups.com.

To post to this group, send email to bigbluebu...@googlegroups.com.
Visit this group at https://groups.google.com/group/bigbluebutton-setup.
To view this discussion on the web visit https://groups.google.com/d/msgid/bigbluebutton-setup/739bf8c1-ab1e-4ebd-aad4-cdad8dbcd403%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Christopher Herbert]

Wouldn't that be true whether it was via the coturn server or not? The connections are fine from external sites with apparent full UDP access (ie the mobile data network works fine, internal network is fine - mixing both is fine). Full mic and video is fine except from users behing a firewall ... so clearly a coturn related issue.

[Chad Pilkey]

I'm confused. I thought you'd said in an earlier message that mobile networks didn't work after setting up the TURN configuration, but now you're saying that mobile do work and it's just networks with UDP blocked that don't work.

What browsers and OSs have you tested with? I know that iOS Safari and Edge are temperamental with TURN servers. If those same browser and OS combos can connect to test.bigbluebutton.org without issue though then it could be an issue with your TURN server. If the restricted users can't connect to audio on our server then it might be a different restriction as our TURN servers use the exact same configuration that we have in the documentation. Also, if the restricted users can connect to our server it would be good to to determine which candidate pair is getting selected when connecting to our server because if they aren't even choosing the TURN candidate then there's a different problem. The easiest way to find the selected candidate pair is to use Firefox and go to "about:webrtc" and it will list the candidates tried and which one succeeded.

[Christopher Herbert]

Hi Chad, you are right and both are true. I probably didn't make everything as clear as I could have. As a quick recap ...

1) Got it to work locally

2) Got it to work with mobile data (small tweak to some settings, forgotten which it was now, but an ip address IIRC

3) built the coturn server

4) updated the BBB server to ref the coturn server -> killed progressively in order the mobile connection then on a reboot everything died.

5) as I was working on a VM, I'd cloned a copy at stage 2 above and I am now working on that copy. Coturn server is configured but is not referenced within the BBB server

As an aside and in case it is relevant/insightful, a BBB server reboot requires the environment to be manually reloaded and bbb-conf --restart run otherwie I get 404 errors

Getting access to another machine ouside of my network and mobile is difficult ... I think all the attempts were with Chrome though. It will be next week at least, maybe the week after before I can run the tests you suggest.

Will get back to you with followup when I am able to do that.

Thanks. Very helpful.

[Chad Pilkey]

If you have limited test time with the restricted users you can set up the turn-stun-servers.xml file to have both the defaults and the TURN server configurations in beans with different IDs and then change the referenced beans here, https://github.com/bigbluebutton/bigbluebutton/blob/master/bigbluebutton-web/turn-stun-servers.xml.tmpl#L46, and here, https://github.com/bigbluebutton/bigbluebutton/blob/master/bigbluebutton-web/turn-stun-servers.xml.tmpl#L51. Then you just need to restart the bbb-web process every time you swap. Note that bbb-web can take a minute to start up.

[Christopher Herbert]

Thank you Chad, that will be really useful. I'll look at that before I go try it all ....

[Christopher Herbert]

Yep. That worked, I missed a small thing first time around, or maybe overwrote an earlier change accidentally.

Thanks again