Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why a STUN Server Needs Two Different Public IP addresses

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?

like image 894
metdos Avatar asked Sep 29 '11 08:09

metdos


People also ask

Why would a server need multiple IP addresses?

In order to setup a device that has a default IP address and thus you need to add an address on the same network. In order to use different public IP addresses to avoid firewalls or to avoid being blacklisted in SPAM filters.

Can two public IP addresses be the same?

All ISP or public routers have public IP addresses that they purchase and all have different public IP addresses, they can't be the same, as in fig.

How does a STUN server work?

A STUN server is a server that runs on the public network and replies to incoming requests. The responses it sends out include the public IP address the request was sent to him from. This effectively answers the question “what is my IP address?”

Why is STUN server required?

The reason to have a STUN server is so that the two peers can send the media to each other. The media streams will not hit your signalling server but instead will go straight to the other party(the definition of a peer-to-peer connection), the exception to this would be the case when a TURN server is used.


2 Answers

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.

like image 130
selbie Avatar answered Oct 11 '22 09:10

selbie


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.

like image 20
Jérôme Verstrynge Avatar answered Oct 11 '22 10:10

Jérôme Verstrynge