I want to set up a turn server (coturn) on our company's servers. And I'm not sure which ports should be allowed by outside access. 8443 is a must, using WebRTC. 3478 is a must for credential use. But there's these gazillions of ports which TURN server uses, do they need to be allowed in firewall?Or which ports should be allowed to use CoTURN without problem?
I think it depends on the transport protocols you want to use and the level of security.
With Coturn coturn(git):
The default port for sending (or listening to) STUN/TURN requests is 3478.
TURN listener port for UDP and TCP listeners (Default: 3478). Note:
actually, TLS & DTLS sessions can connect to the "plain" TCP & UDP
port(s), too - if allowed by configuration. For example, the default
listening port can be set to 80 or 443, to go around some strict NATs.
Remember that ports < 1024 may require superuser privileges to start
the turnserver process.
In my project I used also tls listening port but probably it is not necessary:
The default port for sending (or listening to) STUN/TURN over TLS is 5349.
TURN listener port for TLS and DTLS listeners (Default: 5349). Note: actually, "plain" TCP & UDP sessions can connect to the TLS & DTLS port(s), too - if allowed by configuration. For example, the default tls listening port can be set to 443, to go around some strict NATs. Remember that ports < 1024 may require superuser privileges to start the turnserver process. For secure TCP connections, we currently support SSL version 3 and TLS versions 1.0, 1.1, 1.2. For secure UDP connections, we support DTLS version 1.
Also, for establishing at last p2p connection :
Each client will send the data through UDP to the other endpoint:
if it’s sending to a TURN server (to a relay candidate) it will send to a port between 49152-65535 (if it’s sending directly to the other party it will send to any port in the 0-65535 range)
--min-port Lower bound of the UDP port range for relay endpoints allocation. Default value is 49152, according to RFC 5766.
--max-port Upper bound of the UDP port range for relay endpoints allocation. Default value is 65535, according to RFC 5766.
Related
Edit:
I think based on the below answer here, it seems the answer is "client and server basically only communicate on one port, 3478 (or equivalent")
rfc 5766 : Issue when Both devices support TURN
==========================.
I have been reading several sources on TURN, including RFC.
I get the whole premise:
Client creates allocation on TURN server
Client sends data to Peer through TURN that relays via the relayed transport address
Same way around from peer --> Server --> client
Most resources focus on setting up the server and what ports need to be configured.
The point that I am unclear is on the client side:
After the allocation is done and the client can start sending data, do they send that data to the relayed transport address that the Server allocated? Or do they send it to the standard TURN port e.g. 3478, and then the server takes care of looking up the allocation for this client and send it through the relayed address to the peer?
Example:
Client address 192.6.12.123:45677 (let's assume it's the NAT)
TURN server listens on 34.45.34.123:3478
TURN server has done an allocation for client on 34.45.34.123:50678
So when the client wants to send to a peer application data, do they send on port 3478 or port 50678?
My assumption (based also on some wireshark captures I tried) is that the client always send everything on port 3478 and the server takes care to send via the relayed address.
My assumption (based also on some wireshark captures I tried) is that the client always send everything on port 3478
The client will pick a random local port (e.g 45677), but traffic sent from this port goes to the server's port 3478 (or 5349 if using TLS) on the server. The server will forward it through its allocated port (50678) to whatever remote port the other client established during ICE negotiation.
AWS NLB supports TLS termination
https://aws.amazon.com/blogs/aws/new-tls-termination-for-network-load-balancers/
NLB being a Layer 4 load balancer I would expect it to work in a passthrough mode by directing the incoming packets to one of the backends without much of state maintenance (except for the flow tracking)
Are there any details available on how AWS implements the TLS termination in NLB ?
Is it possible to do it with open source tooling (like IPVS or haproxy) or AWS has some secret sauce here ?
The TLS termination itself is just what it says it is. TLS is a generic streaming protocol just like TCP one level up so you can unwrap it at the LB in a generic way. The magic is that they keep the IPs intact probably with very fancy routing magic, but it seems unlikely AWS will tell you how they did it.
In my SO question here, I have an example of how to terminate a TCP session in HAProxy and pass the unencrypted traffic to a backend.
In short, you need to use ssl in the frontend bind section and both frontend and backend configurations require use of tcp mode. Here is an example of terminating on port 443 and forwarding to port 4567.
frontend tcp-proxy
bind :443 ssl crt combined-cert-key.pem
mode tcp
default_backend bk_default
backend bk_default
mode tcp
server server1 1.2.3.4:4567
I am running a FreeSWITCH server on a public domain. I am able to make call from my browser(WebRTC with sipjs) to the FreeSWITCH server from a direct Internet connection.
I am testing it on a Firewall that allows only TCP on port 443. I am running a separate TURN server. I am trying to connect from my browser by specifying TURN server with credentials. I am unable to make it work. PeerConnection is getting closed.
FreeSWTICH server is NOT behind Firewall
Client(browser) is behind Firewall
TURN server is available
Is there any configuration I have to do either in FreeSWITCH server or in the client end(javascript) to make it work?
You need to open UDP ports, cause signalling will go via WSS and media via UDP ports:
mod_sofia to serve SIP signaling via WSS and media via SRTP/DTLS.
https://www.packtpub.com/books/content/configuring-freeswitch-webrtc
Yes, you can use a TURN server. You will have to configure it to listen on port 443 with TCP, because by default a TURN server listens on port 3478.
However, if the Firewall checks for a TLS connection (i.e. for HTTPS), you will have to configure the TURN server as a TURNS (TURN over TLS).
I try to make webRTC app work under corporate firewall that allows only 80 and 443 tcp port, but webRTC use random port(49152-65535). How can i reach?
The solution is to setup a TURN server which is capable to handle traffic on TCP 80 and 443 or use a client library which solves this problem by default (such as the mizu webphone).
You could give coturn a try, it supports TCP transport by default, and if the NAT is very strict and blocks all ports( even outgoing ones) other than 80 and 443, you can set the listening-port as 80 and tls-listening-port as 443 in the TURN server configuration before starting it.
When I connect to SSH I use port 22 as destination, but when the reply comes back, does it come in on port 22 as well? Or is the client source port randomly assigned as in other TCP communication?
If set up a firewall allowing outbound traffic to port 22 - Do I also need to allow incoming traffic on port 22?
The client SSH port is randomly assigned, as in most client/server systems over TCP/IP.
Were the client port fixed, you would not be able to open multiple SSH connections from the same client IP address, as the connections would be indistinguishable on an IP protocol level. The client port number is the only piece that makes the connection unique (client IP, server IP and server port being the same).
You do not need to allow the incoming traffic though. There is only one outgoing connection in SSH (the responses from the server come over an existing connection).