Why a STUN Server Needs Two Different Public IP addresses

Question

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?

Veal

Answer 1

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.

Illimitable

Alas, the classic stund implementation does not support two IP addresses on two servers. The two IPs might be on the same NIC or not, but stund tries to bind to both, so they must be on the same server. – Dissertate

Answer 2

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.

Halicarnassus

This explanation helped me a lot. If I understand correctly it means the second IP on the STUN server will be employed only if the client's STUN request indicates for it to be used. I've been thinning about STUN in terms of WebRTC and (via wireshark) I never seem to see any secondary IP from a STUN server reach out to me. My theory is this is because all that the second IP would confirm is UDP hole punching is succeeding and in WebRTC, if it doesn't succeed, those candidates are going to fail anyway so the additional check is of no consequence. Is my understanding correct here? – Coinstantaneous

@Coinstantaneous - the second IP is only needed for determining NAT type (i.e. diagnostics and debugging), not for actual hole punching. The client can send a "binding request" to the server to ask for its IP/port mapping. These binding requests can indicate that the response can come from the server's alternate IP and/or alternate port. 99% of the client requests to stun.stunprotocol.org are simple binding requests to/from the primary IP and port 3478. A handful of clients make use of the port redirection attribute. There's been a few SIP phones that want to use both ports. – Halicarnassus

Answer 3

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.

Punner