According to RFC5766, it seems that TURN server should have UDP port 49152 - 65535 open for relay.
In all cases, the server SHOULD only allocate ports from the range 49152 - 65535 (the Dynamic and/or Private Port range [Port-Numbers]),
However, some of the TURN servers, such as Coturn, allow you to specify even smaller set of UDP ports for relay.
Because Docker consumes substantial amount of CPU/RAM resources when large port mappings need to be created between a container and a host, I am interested in using smaller set of ports to mitigate high resource usage when I am deploying dockerized TURN server.
I want to know the implications of using smaller set of UDP ports, such as from 49500-50000 (Using 500 UDP ports open) vs 49152-65535 (Using ~16400 UDP ports).
What are the downside of using smaller set of ports for relay? If there is no downside, why does TURN recommend using so many UDP ports for relay?
You can use as few ports as you want, it just limits the amount of allocations you can have.
Each TURN Allocation (session) needs a dedicated 3-Tuple (IP/Port/Protocol)
Related
If I am building a WebRTC app and using a Selective Forwarding Unit media server, does this mean that I will have no need for STUN / TURN servers?
From what I understand, STUN servers are used for clients to discover their public IP / port, and TURN servers are used to relay data between clients when they are unable to connect directly to each other via STUN.
My question is, if I deploy my SFU media server with a public address, does this eliminate the need for STUN and TURN servers? Since data will always be relayed through the SFU and the clients / peers will never actually talk to each other directly?
However, I noticed that the installation guide for Kurento (a popular media server with SFU functionality) contains a section about configuring STUN or TURN servers. Why would STUN or TURN servers be necessary?
You should still use a TURN server when running an SFU. To understand diving into ICE a little bit will help. All SFUs work a little differently, but this is true for most.
For each PeerConnection the SFU will listen on a random UDP (and sometimes TCP port)
This IP/Port combination is giving to each peer who then attempts to contact the SFU.
The SFU then checks the incoming packets if they contain a valid hash (determined by upwd). This ensures there is no attacker connecting to this port.
A TURN server works by
Provides a single allocation port that peers can connect to. You can use UDP, DTLS, TCP or TLS. You need a valid username/password.
Once authenticated you send packets via this connection and the TURN server relays them for you.
The TURN server will then listen on a random port so that others can then send stuff back to the Peer.
So a TURN server has a few nice things that an SFU doesn't
You only have to listen on a single public port. If you are communicating with a service not on the internet you can just have your clients only connect to the allocation
You can also make your service available via UDP, DTLS, TCP and TLS. Most ICE implementations only support UDP.
These two factors are really important in government/hospital situations. You have networks that only allow TLS traffic over port 443. So a TURN server is your only solution (you run your allocation on TLS 443)
So you need to design your system to your needs. But IMO you should always run a well configured TURN server in real world environments.
I have a server listening on UDP port 22000 at a google compute engine.
I can connect from the internet, any machine no problem, but I cannot connect from the local machine.
The exact same code runs normally in any other (non-google) Linux machine.
My only changes to the default compute engine settings were to add a firewall rule allowing incoming UDP at port 22000.
Any help most welcome!
jaime
Solved!
Apparently in these machines / kernel UDP sockets need to have a name (bind) before sending - never needed in other machines where I installed the server.
So in the sequence:
socket()
settimeout(..)
setsockname( .. )
socksendto( .. )
sockrecvfrom( .. )
... I've always avoided the "setsockname" as per the Lua socket documentation (http://w3.impa.br/~diego/software/luasocket/udp.html#setsockname):
Note: This method can only be called before any datagram
is sent through the UDP object, and only once. Otherwise, the system
automatically binds the object to all local interfaces and chooses an
ephemeral port as soon as the first datagram is sent. After the local
address is set, either automatically by the system or explicitly by
setsockname, it cannot be changed.
... when sending was the first operation.
For some reason, here it is needed. To be specific, I've:
setsockname( '*', 0 ) - that is, bind to all local addresses, use an ephemereal port.
I'm looking for suggestions about approaches to allow multiple applications to use port 80 for communication.
I know it's impossible, or at lease not sensible to have multiple applications to actually bind to port 80, however, I've seen appliances when there is a device that provides both a web interface (HTTP) and RTSP with RTP using port 80.
I have two ideas on how this is achieved:
Are those custom made apps that implement all the functions?
For example the same binary is used for a web server and a RTSP server. That seems kind of limiting due to the fact that you would have to do sever modifications to already developed apps if you want, for example, Apache and openSSH both on port 80.
Are there a "port 80 multiplexers" sort of a pattern?
For example, a parser application that listens to port 80 and depending on the header of the received package, passes the package to the required application.
Found some related references, will give them a try.
https://bbs.archlinux.org/viewtopic.php?id=99457
http://www.rutschle.net/tech/sslh.shtml
I really don't think this is possible in a standard way: port number is actually the one that allows multiplexing among different applications in TCP and UDP protocols. More generic, TSAP, Transport Service Access Point allows multiplexing at the transport layer. TSAP is the port in protocols such as TCP, UDP, or SCTP.
One reason you may want two applications listening on the same port is that a second application can monitor or process in some other way the messages received, and eventually processed, by the first one. In this case, using pcap library other applications could read messages received by the main application that will probably response those messages.
Netfilter can also be useful, http://www.netfilter.org/
However, if you intend two applications to respond messages that arrive to the same port, that would be tricky and would have dependency on each application.
In this response I'm assuming you are thinking of applications listening to the same port at the same IP address. Something different is working with multihost servers where two applications could listen to same port number in different IP addresses.
I want to develop a P2P Gaming application. What is the fastest and efficient way to implement NAT traversal and Peer discovery. I have read about STUN and TURN server. But what are the Open source parts available and how can I use them?.
1. Does those STUN server work on 3G networks?
2. Does UDP HOLE PUNCHING works on 3G networks?
If you have a videogame, you probably want to have a central server that contains all the game data and allow the users to be clients. You know, like Puzzles and Dragons, where you have a username and password and sign in to a server.
Google "Stun Client" and "ICE protocol". There are plenty of open source implementations
STUN fails on mobile networks because mobile networks have symmetric, large scale NAT. Traversing that kind of nat doesn't work with STUN (see reason below)
Why Mobile Broadband NAT cannot be bypassed?
It boils down to statistics. In order for a connection to be established, you have to send a packet into the port that they are at and they have to send a packet into the port that you are at. If you send to the wrong port number or they send to the wrong port number, you miss and no connection is established. If both of you simultaneously bind to a port and send out a packet directed at the other's ip address, you have a 1 in 65535 (65535 being the number of port on an ip address) chance of sending a packet into their port and they have a roughly 1 in 65535 chance of sending a packet into your port. So the chance of you establishing a connection is (1/65535) * (1/65535), or (1 / 65535^2).
You can't know your port number for any subsequent connection because for every new outbound connection, the router randomly gives you a new port number on the interval between 1024 and 65535. So if you ask a server what you ip and port number is, it may tell you the right ip (your ip address doesn't change very often unless you turn off your phone or something like that), but the port number will change. If you try to guess the port number there is a ( (65535-1024-1) / (65535-1024) ), or 99.998% change of you guessing it wrong, assuming that the number of possible port numbers to choose from is (65535-1024).
So unless the port numbers are predictable (which in many 4G networks they are not), you're hosed - no chance.
Your best bet is to use stun and not support evil routers.
I'm trying to transmit data in UDP datagrams into a client in external location to a pc in my local lan.
But my network is over a ADSL modem sending to a pc with Slackware, this pc redirect packages into other pcs.
I'm using socat to redirect UDP:
socat -v udp-listen:1935,fork,reuseaddr udp:192.168.0.40:37000
In LAN the conection is fine, but external IPs don't work.
Somebody help?
I don't think socat is the culprit, however consider to use stone instead of socat, because using a fork() for each received packet is a bit weird. Stone is called in your case like this (I think):
stone -n -d -d -d -d 192.168.0.40:37000/udp 1935/udp
Now why external IPs perhaps do not work. Sadly your text does not tell much about your setup, so I have to guess:
It depends on your firewall/modem/router if it is able to forward UDP packets. Usually, if you initiate the UDP requests from the inside, the router will open a NAT connection, which often means, that not only the source IP of the packets change, but the source port as well. As UDP is connectionless, UDP NAT connections usually time out very quickly, say after 5 minutes, if no data is transferred on them.
If the UDP must be opened in the opposite direction (from Internet to Intranet), the router usually discards all the UDP packets coming in from Internet, because it does not know where to forward them to. A router cannot just choose some arbitrary machine, this would be a security hole. So in the "Internet connecting to a machine behind the router" you must open the UDP port on the router and let it forward to the right machine. In that case packets sent from your internal machine will get their source IP and the source port rewritten, the machine on the Internet always will see the packets as coming from your router. So except for the additional rule in the router this case is the same as the outgoing case.
Note that there are several different ways how to make NAT (symmetric, etc.) and several methods on how to open a port on the router (Config, UPnP, etc.) so the ways to poke some holes into it always depends on your hardware capabilities. This all cannot be answered here.
Some other ideas what might go wrong as well:
Some UDP protocols encode IP addresses within the payload. In that case it is not enough just to forward the packets, you must change the payload as well to correct the IP addresses exchanged to enable all machines to talk together. Such UDP protocols are badly designed, anyway, because you never should assume that two arbitrary machines can directly talk with each other, so all good protocols should support easy proxying.
Some ISPs filter certain UDP ports, for arbitrary reason. If you have problems talking from Internet to your DSL, try with two external machines directly connected to different ISPs. If these can talk via UDP check if you can talk from your Intranet to one of the external machines. If this still works, this means, that you can talk backwards as well, as usually UDP is not a directed protocol, but if there is some NAT involved you somehow must make sure that the communication ports stay open.
Mobile Internet plans often do not support P2P. This probably means, those plans do not support Internet at all, as IP, by definition, is P2P. What the ISPs really want to say with "no P2P" is (my guess), that connections from Internet to the mobile device are not supported. In that case you always must initiate a connection from the mobile device, so you cannot use push methods (Internet to Mobile), the mobile device always must pull (data from Internet). Some broadband/cable providers might do the same. Usually you can see this if your ISP hands out an IP in the 10.x.y.z range to you.
There might be another trick how to get the connection working:
Ask your ISP to get some IPv6. Perhaps use 6to4. With IPv6 you eliminate NAT completely, your local LAN then directly interconnects to the Internet on IPv6. Be sure to activate your firewall/iptables on your Intranet host on the IPv6 interface, else you might see Intruders very quickly.
HTH