COTURN & Meet behind a Firewall (LAN/NAT)?

pixel

@fbartels said in COTURN & Meet hinter der Firewall (LAN/NAT)?:

you have to use the non-ssl port here. Only few browsers support turn over ssl.
The error should be more apparent if you look into your browser console.

I cannot use 443 because this port is already in use on com01.

To test it, I start it in the LAN in the browser and on the mobile phone (via 4G). On the PC (browser console) I see no error. I do not have the console on the mobile phone.

fbartels

@pixel said in COTURN & Meet hinter der Firewall (LAN/NAT)?:

I cannot use 443 because this port is already in use on com01.

What I meant is that you need to use the port 3478 and not 5349 when you specify the turn server that Meet should use.

pixel

Excuse me. I had not written that but I had tried that before. I have now changed the line again:

listening-port=3478
#tls-listening-port=5349

In the app setting changed the port accordingly … run join-script and restarted everything.

Now I see at least a hint in the browser console:

pixel

Where can I debug on the Kopano server what happens when the clients connect?

pixel

Or can I somehow test the function of the specified turn server externally (browser or command)?

longsleep

@pixel TURN servers are not really meant to be run behind NAT - having that said, it is possible if you carefully setup your filewall rules and do 1 to 1 port forward in both directions.

See https://github.com/coturn/coturn/blob/master/examples/etc/turnserver.conf#L110 for hints.

Keep in mind that for full NAT traversal support, your TURN server needs to be available on port 443 and has to be available on two different public IP addresses.

Kopano offers the TURN service to subscribers which are unable or unwilling to setup their own TURN server.

longsleep

@pixel said in COTURN & Meet behind a Firewall (LAN/NAT)?:

Where can I debug on the Kopano server what happens when the clients connect?

You can use https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ to interact with TURN and/or STUN servers for testing. Its more for developers, but it might be of some use to you.

pixel

@longsleep said in COTURN & Meet behind a Firewall (LAN/NAT)?:

@pixel TURN servers are not really meant to be run behind NAT - having that said, it is possible if you carefully setup your filewall rules and do 1 to 1 port forward in both directions.
See https://github.com/coturn/coturn/blob/master/examples/etc/turnserver.conf#L110 for hints.

Thank you for pointing this out. Like the other VMs, the TURN server is accessible under 443 via HA proxy.

I have already set the value “external-ip=…” to the external WAN IP of the local gateway. However, I cannot find any indication in the readme that I need two external IPs.

I suspect it is due to the 1:1 port forwarding in the outgoing direction. Which ports with which protocol are required here?

We have tried using the Kopano server (https://ucs-turn.kopano.com/turnserverauth/). Despite a good local data line, we often have a standstill with the video. In addition, all data should “stay” here in the house as far as possible with regard to data protection.

pixel

I spent a lot of time with COTURN at the weekend. Just so that I understand it correctly, I would like to ask again

@longsleep said in COTURN & Meet behind a Firewall (LAN/NAT)?:

and has to be available on two different public IP addresses.

The config mentioned in the link says:

# TURN Server public/private address mapping, if the server is behind NAT.
# In that situation, if a -X is used in form "-X <ip>" then that ip will be reported
# as relay IP address of all allocations. This scenario works only in a simple case
# when one single relay address is be used, and no RFC5780 functionality is required.
# That single relay address must be mapped by NAT to the 'external' IP.
# The "external-ip" value, if not empty, is returned in XOR-RELAYED-ADDRESS field.
# For that 'external' IP, NAT must forward ports directly (relayed port 12345
# must be always mapped to the same 'external' port 12345).
#
# In more complex case when more than one IP address is involved,
# that option must be used several times, each entry must
# have form "-X <public-ip/private-ip>", to map all involved addresses.
# RFC5780 NAT discovery STUN functionality will work correctly,
# if the addresses are mapped properly, even when the TURN server itself
# is behind A NAT.
#
# By default, this value is empty, and no address mapping is used.
#
#external-ip=60.70.80.91
#
#OR:
#
#external-ip=60.70.80.91/172.17.19.101
#external-ip=60.70.80.92/172.17.19.102

Does this mean I need two public IP addresses bound to the WAN interface of my pfSense or is one public IP address sufficient?

As I understand it, I do not necessarily need the second public IP address, but only in:
Does this mean I need two public IP addresses bound to the WAN interface of my pfSense or is one public IP address sufficient?

As I understand it, I do not necessarily need the second public IP address, but only in:
In more complex case …
… RFC5780 NAT discovery STUN functionality will work correctly,

longsleep

@pixel the TURN server is there to allow connection even if clients have firewalls. Thus the need for it in its various operation modes differs. Some clients might not be able to connect without two WAN IP addresses. This is related to support for RFC 5780 in coturn. Same goes for using port 443, using tcp and/or udp.

Since the TURN server has a lot of requirements to network and bandwidth it is usually put in firewalled into a Datacenter with good network connectivity for all expected users.

Note that the even with a TURN server, the actual stream data is still end to end encrypted.

pixel

Thanks for the info. We have a synchronous fiber connection here (150/150). However, only one fixed IP.
So the thought was obvious to place the Coturn server here.

We have an external webserver but we don’t have full access to it to install Coturn.

I will ask the ISP if we can get a second fixed IP.

I am still reading through the documentation and will also try to get it running.

What is confusing for me is that I find many different statements on the web about this use case:

Works with second IP
Is complete nonsense
Works also with one IP