I have took a look to STUN Server settings in openfire, and this statement from there:
"In order to act as a STUN server, two different public IP addresses on the same machine are required, as well as two different port numbers for each IP."
I have researched on google, and generally stun servers need two public IPs, what is reason for that?
For attempting to establish P2P connectivity, the STUN binding request and response to/from the STUN service's primary address (IP and port) is all that really matters. The mapped address returned in the response body of this request is passed (via XMPP or other service) to the remote node that the local client is attempting to establish directly communication with.
The second IP and port that the STUN service listens on are useful for determining NAT port mapping behavior and NAT filtering behavior.
By making binding requests to the alternate IP:port on the service, a client can discover if his NAT has consistent mapping semantics for local ports. In the event he gets different port mapping values for each test, the client can conclude it is behind a "symmetric NAT" - which are the most difficult to traverse for P2P.
By sending up a bind request with a "change request" attribute that asks the service to respond from the other IP or port, a client can detect if his NAT just filters datagrams from remote hosts based on IP and port, or allows for datagrams from alternate ports on hosts it has sent outbound datagrams to.
The mapping behavior and filtering tests only provide limited information for subsequent P2P connections. In the case of determining a symmetric NAT is between the host and the Internet, some implementations may observe the NAT to have a consistent incremental value of the port value in each binding response. (e.g. the external port observed by the STUN service increases by one). As such, the client can offer an IP and guessed port number for the remote client to try to send to instead of the one mapped back from the first binding request. Or the client may use this behavior/filtering test for logging. Or to automatically allocate a relay in the event of symmetric NAT.
Because in some rare cases, the behavior of NAT translation is a function of the target IP address. Meaning, you must 'ping' two different IP addresses to find the precise behavior of the NAT (does it depend of the target IP address or not?)
If you 'pinged' twice the same server with two distinct ports, that would not cover this case properly (i.e., you would not be covering all your bases).
P.S.: The two IP addresses don't need be on the same server, it could be different servers.
I'm guessing that it is required to identify the type of NAT being performed - some NAT will use the same source IP address and encode the session id via the port number (I think it's called cone NAT but not sure), some NAT will use a combination of source IP and port to encode the session ID. The answer the STUN server needs to give the client is different based on NAT type.
Related
I'm trying to follow the code given here to implement NAT hole punching in Node.js. I'd like to know if the server is strictly necessary. Having read about hole punching, I am under the impression that the purpose of the server is to allow the clients to exchange some information (including but not limited to their addresses and ports they want to communicate on) so that they can proceed to talk directly. Assuming the clients already had each other's information (again, including but not limited to their addresses and ports), would the server still be necessary? If so why and if not, how could this be implemented?
For instance, say one were to build an application where client_A prints out all information that would have been transmitted to the server for user_A to read, who then sends this to user_B, who then submits this info to client_B (this could be done via email for example). Wouldn't this avoid the need for a server?
Here is another explanation of why I think it might be possible to remove the server in the middle:
In NAT hole punching (assuming I understand it correctly), the communications begin when client_A sends a message to the server. The message contains some information that the server then passes on to client_B when client_B contacts the server. After this point, client_A and client_B are able to communicate directly without the need for the server. I am under the impression that once a direct connection between client_A and client_B has been established, the server could go offline and the two clients would still be able to communicate directly with one another. If this is the case, then I would imagine that any information that is being used to maintain this connection (be that addresses, ports, or any other kind of info) could be exchanged through any other channel (eg: email, a handwritten letter, a voice call, etc) at the beginning of the protocol, and then the connection could be established without ever needing the server.
Regarding 'tricking' the router
As manishig pointed out to me in a comment (thanks), NAT hole punching also requires tricking the router. If I understand correctly (please correct me if not) the router is tricked by having the router store the info for directing incoming packets from the server to client_A, however, these packets are actually coming from client_B after the initial phase of the protocol. If this is a correct description of the problem, is there a way to trick the router that doesn't require using a server?
There are ways to communicate between two remote computers over the internet without an intermidiate server, but IMO it is not the preferred way.
Why an intermidiate server is needed?
If client_A and client_B are both in the same LAN (e.g your home/office network) you can make sure (configure on the clients side and/or the router) that they will have a static ip address over this LAN and they can just talk freely.
E.G: If client_A is listening on port 8080, client_B can create a connection to client_A_ip on port 8080
Over the internet any packet sent is passed through NAT usually at least twice. One time after going through your LAN (e.g your home/office router) and at least once over an ISP endpoint. Which means you have no controll over the public ip and port assigned to your packet.
Now not only that you don't have controll over your packet's assigned public ip and port, these are also not static. They won't change while you have an active TCP connection, but you don't have any other guarantee from your ISP regarding your assigned public ip and port.
The intermediate server`s purpose is to dynamically update each client with it's peer info and also keeping the tcp connection open, so that peer to peer comunication will be available.
Alternative solution to an intermidiate server (Not recommended)
If you want your clients to communicate without an intermidiate server you can buy a public static ip from your ISP (if they support it) and then there are ways you can make (with some config) that one of your clients have a public static ip and port that the other client can connect to.
But I wouldn't recommend it, since it requires some understanding in IT and security risks.
Also if both client's are portable and connect to different networks all the time it's not a valid solution
How we can share any type of data over the two separate networks without violating security mechanisms using UDP ?
There are a few things you'll have to remember:
Every network has its firewall, and it depends on the firewall rules, whether to allow your traffic into the network or not. First, ask your client or receiver to make changes in the firewall so that it accepts your IP address and also remember most of the systems have an edge firewall too.
Be clear with the type of connection i.e., p2p (or) server & client. It's better if it is a client & server type connection.
UDP by definition is NOT a connection-oriented protocol, so there is no state to keep track of as far as OSI layers 2-4 are concerned. All incoming UDP connections are treated as "new" or the same.
Also, see that none of the systems is under NAT connection, as the router will remember the IP and port of the device just for a while. And if there is any delay in response from client-side then the system under NAT will not know the IP or the port of the device, where it is supposed to send the traffic.
I am currently implementing a (UDP) p2p application in C using the "hole punching" method. I found really illustrating previous posts by J. Selbie where he explains the basics
and proceeded accordingly (post1, post2) but probably i'm missing something and only one of the peers is receiving data while the other one is not.
Here are the steps i am taking:
Setup: One of the peers is connected to a 4G cellular dongle (NAT A) and the other one is connected to a router that goes to the ISP provider (NAT B).
These are the results reported for stunclient (stuntman client) for both NATs.
NAT A:
Binding test: success
Local address: X1:48383
Mapped address: Y1:28265
Behavior test: success
Nat behavior: Endpoint Independent Mapping
Filtering test: success
Nat filtering: Address and Port Dependent Filtering
NAT B:
Binding test: success
Local address: X2:49158
Mapped address: Y2:49158
Behavior test: success
Nat behavior: Endpoint Independent Mapping
Filtering test: success
Nat filtering: Address and Port Dependent Filtering
Now, according to these results, it is my understanding, that both NATs have a reasonable behavior and hole punching might succeed (note that NAT A does not do port preservation).
Hole punching attempt:
Both clients contact a public facing server (STUN/rendezvous) by means of UDP to discover/interchange ip:port pairs. When each of the clients receive the response from the server, they send a UDP datagram to the other peer (ip:port as seen by the contacted public server), and then proceed to send some more and receive and reply the message to the address from which it came.
I am sending the datagrams using the same socket that contacted the public server, only changing destination ip:port on the sendto function.
The thing is, that the host behind NAT A (hooked up to the 4G dongle) always receives the message, and in spite of replying to the correct ip and port of destination, the other one behind (NAT B) never gets the message. Any ideas what i am missing here ? or how to diagnose the problem ??
Thanks in Advance.
This is standard and general scenario where p2p(peer-to-peer) call between cellular and wifi(ISP) network is not possible. Now why?
Why?: All of the cellular network uses a cost effective method where no user can have a dedicated public IP or NAT. Meaning mobiles public IP may change after a few hour or so. As a result cellular network provider can use less number of public IP for huge number of user. This process is done generally by assigning new ip:port for every request, which is a feature of symmetric NAT. So in your case as the NAT B is Nat filtering: Address and Port Dependent Filtering that means if the data comes from NAT A has unique ip:port for every send/request then the NAT B will filter the data and the call will fail.
Solution: In general you need a relay server hosted on public IP which will receive the data from A and forward it to B and B will also do so without doing any filtering. This kind of server is called TURN server.
Now I am not sure why your stuntman test client is detecting PRC NAT(Nat filtering: Address and Port Dependent Filtering) for both A and B. For A it must be Symmatric NAT as it is on cellular network.
RFC 5780 for STUN defines a Response-Origin attribute for STUN messages responses sent by the server back to the requesting client.
It describes it as:
The RESPONSE-ORIGIN attribute is inserted by the server and indicates the source IP address and port the response was sent from. It is useful for detecting double NAT configurations. It is only present in Binding Responses.
How does the client use the server's source IP and port to detect double NAT configurations? Couldn't the source address information be just as easily read from the UDP packet's source field, seeing as inbound NAT only re-writes the destination address and not the source address?
Server can tell two things:
i) What IP address it sees for you. If it does not match your ip address, you know there is a NAT between you and the server. You have been translated.
ii) What IP address it sees for the remote peer, and the IP address the remote peer communicated to the server. If they don't match, the remote peer is behind NAT too.
Hence, you can find whether you are dealing with a double-NAT situation.
Now this is not to be confused with situation where there are two NATs between you and the server for example. But in this case, you don't need to worry, because the server will work with the last NAT on your way from you to the server.
Such as Skype/Team viewer/Logmein etc application, which send audio/video behind NAT (behind firewall). But when i make a small tiny application which send text to another NAT location it failed to do the same.
Example:
Sender:
-> Public ip: 91.1.2.3 My lan ip is: 192.168.1.2 with port 14446 udp
-------> Data format: RTP packets
Receiver:
<------- Data received: 0 packets
-> Public ip: 92.1.2.3 Friend lan ip is: 10.0.0.2 with port 14446 udp
* same in both way
How others does this? What is the way of doing peer 2 peer application development to overcome NAT issues? Always we have public ip's and mostly it has NAT issues.
But how does then Skype works in such cases too? Do we have a audio/video port range for UDP or always UDP is open from anything? But mine does not work above range ports for UDP i also tried. What is the secret? that is making me curious!!.
Note:
My goal is audio packets handling where i believe too much filtering or firewall cause latency and delay and other issues gets involved relatively too. So i would like to know very clearly for my application that some of the ports (which port ranges?) can be used for such purposes, where it really not blocking development stress.
There are a number of types of NATs, which vary in what traffic they'll allow in.
See the Wikipedia article on NATs
For most NATs, STUN will let you open ports AND find out what port you opened (may be different than the port you sent from). In SIP and RTSP you'd typically provide the external IP and port determined by STUN to the other end.
A fully-symmetric NAT means that STUN won't let you use a 3rd-party server to prop ports via STUN, so you'll have to use UPnP (if enabled) or map ports in the router (or set up triggers), or you'll have to play evil games to make both sides think they initiated the connection. (Not easy and not guaranteed.)
See the ICE & TURN specs (RFCs) from the IETF for detailed mechanisms to traverse NATs - though note that in some cases you must use an external proxy to forward packets.
One common solution is that the client program connects outward to the server and thus establishes a connection. Most firewalls allow outward connections - the assumption being that you are trusted and can always connect to the outside. When the server then wishes to send a message to you, it responds on the open connection.
I believe the port that you use is what is usually used to determine if it should be allowed or not. Certain ports are always let through. I'm not sure of the exact ports, but that will be different for all NATs and firewalls.