STUN

STUN stands for Session Traversal Utilities used for NAT (Network Address Translation). It is a server-client protocol for assisting devices behind a NAT firewall or router with their packet routing. RFC 5389 redefines the term STUN as ‘Session Traversal Utilities for NAT’.

A STUN server operates on the public network and responds to the common question – ‘What is my IP address?’ Using the STUN server, clients can access information about their public address and the type of NAT running on the gateway. It can also be used to check what Internet port is linked using NAT to their local port. For this reason, other protocols such as Interactive Connectivity Establishment (ICE), the Session Initiation Protocol (SIP) and WebRTC use STUN.

• STUN enables a device to find out its public IP address and the type of NAT service it’s sitting behind.
• STUN operates on TCP and UDP port 3478. The server will also require users to carry out tests on a secondary IP and port number.
• STUN is not universally supported by VOIP devices yet. Support as of 2015 is fairly good, but legacy devices may lack it.
• STUN may use DNS SRV records to find STUN servers attached to a domain. The service name is _stun._udp or _stun._tcp

Definitions (from the RFC)

• STUN Client: A STUN client (also just referred to as a client) is an entity that generates STUN requests. A STUN client can execute on an end system, such as a user’s PC/ router, or can run in a network element, such as a conferencing server.
• STUN Server: A STUN Server (also just referred to as a server) is an entity that receives STUN requests, and sends STUN responses. STUN servers are generally attached to the public Internet.

Various types of NAT (still according to the RFC)

• Full Cone: A full cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Furthermore, any external host can send a packet to the internal host, by sending a packet to the mapped external address.
• Restricted Cone: A restricted cone NAT is one where all requests from the same internal IP address and port are mapped to the same external IP address and port. Unlike a full cone NAT, an external host (with IP address X) can send a packet to the internal host only if the internal host had previously sent a packet to IP address X.
• Port Restricted Cone: A port restricted cone NAT is like a restricted cone NAT, but the restriction includes port numbers. Specifically, an external host can send a packet, with source IP address X and source port P, to the internal host only if the internal host had previously sent a packet to IP address X and port P.
• Symmetric: A symmetric NAT is one where all requests from the same internal IP address and port, to a specific destination IP address and port, are mapped to the same external IP address and port. If the same host sends a packet with the same source address and port, but to a different destination, a different mapping is used. Furthermore, only the external host that receives a packet can send a UDP packet back to the internal host. You can use a DH2i NAT test to determine if your site is behind a Symmetric NAT device.

Closing words (also from the obsolete RFC 3489)

In Closing

The problems with STUN are not design flaws in STUN. The problems in STUN have to do with the lack of standardized behaviors and controls in NATs. The result of this lack of standardization has been a proliferation of devices whose behavior is highly unpredictable, extremely variable, and uncontrollable. STUN does the best it can in such a hostile environment. Ultimately, the solution is to make the environment less hostile, and to introduce controls and standardized behaviors into NAT. However, until such time as that happens, STUN provides a good short term solution given the terrible conditions under which it is forced to operate.

Standard documents

STUN RFC RFC 3489, now obsolete (Oct 2008)
STUN RFC RFC 5389 (Current as per October 2008)

Update to STUN protocol

STUN standard is currently has been rewritten with RFC 5389. See details in STUN-bis

Extensions to STUN protocol

RFC 5780 defines a STUN extension to support the NAT Behavior Discovery procedure. It borrows some details from the original RFC 3489 STUN specs.
RFC 5769 defines test vectors for STUN implementation validation.

Software

• STUNTMAN – is an open source STUN server and client library
• vovida.org has an open source STUN server: vovida.org STUN server
• a Java STUN library (includes a STUN client): JSTUN
• a Microsoft windows based simple STUN server: miniSipServer
• PJNATH library from pjsip.org project is an Open Source NAT traversal library supporting STUN, TURN, and ICE.
• STUN Client and Server – implement an easy STUN server and client on Windows and Linux.

Public STUN servers

• iphone-stun.strato-iphone.de:3478
• numb.viagenie.ca:3478
• stun.12connect.com:3478
• stun.12voip.com:3478
• stun.1und1.de:3478
• stun.3cx.com:3478
• stun.acrobits.cz:3478
• stun.actionvoip.com:3478
• stun.advfn.com:3478
• stun.altar.com.pl:3478
• stun.antisip.com:3478
• stun.avigora.fr:3478
• stun.bluesip.net:3478
• stun.cablenet-as.net:3478
• stun.callromania.ro:3478
• stun.callwithus.com:3478
• stun.cheapvoip.com:3478
• stun.cloopen.com:3478
• stun.commpeak.com:3478
• stun.cope.es:3478
• stun.counterpath.com:3478
• stun.counterpath.net:3478
• stun.dcalling.de:3478
• stun.demos.ru:3478
• stun.dus.net:3478
• stun.easycall.pl:3478
• stun.easyvoip.com:3478
• stun.ekiga.net:3478
• stun.epygi.com:3478
• stun.etoilediese.fr:3478
• stun.faktortel.com.au:3478
• stun.freecall.com:3478
• stun.freeswitch.org:3478
• stun.freevoipdeal.com:3478
• stun.gmx.de:3478
• stun.gmx.net:3478
• stun.halonet.pl:3478
• stun.hoiio.com:3478
• stun.hosteurope.de:3478
• stun.infra.net:3478
• stun.internetcalls.com:3478
• stun.intervoip.com:3478
• stun.ipfire.org:3478
• stun.ippi.fr:3478
• stun.ipshka.com:3478
• stun.it1.hr:3478
• stun.ivao.aero:3478
• stun.jumblo.com:3478
• stun.justvoip.com:3478
• stun.l.google.com:19302
• stun.linphone.org:3478
• stun.liveo.fr:3478
• stun.lowratevoip.com:3478
• stun.lundimatin.fr:3478
• stun.mit.de:3478
• stun.miwifi.com:3478
• stun.modulus.gr:3478
• stun.myvoiptraffic.com:3478
• stun.netappel.com:3478
• stun.netgsm.com.tr:3478
• stun.nfon.net:3478
• stun.nonoh.net:3478
• stun.nottingham.ac.uk:3478
• stun.ooma.com:3478
• stun.ozekiphone.com:3478
• stun.pjsip.org:3478
• stun.poivy.com:3478
• stun.powervoip.com:3478
• stun.ppdi.com:3478
• stun.qq.com:3478
• stun.rackco.com:3478
• stun.rockenstein.de:3478
• stun.rolmail.net:3478
• stun.rynga.com:3478
• stun.schlund.de:3478
• stun.sigmavoip.com:3478
• stun.sip.us:3478
• stun.sipdiscount.com:3478
• stun.sipgate.net:10000
• stun.sipgate.net:3478
• stun.siplogin.de:3478
• stun.sipnet.net:3478
• stun.sipnet.ru:3478
• stun.sippeer.dk:3478
• stun.siptraffic.com:3478
• stun.sma.de:3478
• stun.smartvoip.com:3478
• stun.smsdiscount.com:3478
• stun.solcon.nl:3478
• stun.solnet.ch:3478
• stun.sonetel.com:3478
• stun.sonetel.net:3478
• stun.sovtest.ru:3478
• stun.srce.hr:3478
• stun.stunprotocol.org:3478
• stun.t-online.de:3478
• stun.tel.lu:3478
• stun.telbo.com:3478
• stun.tng.de:3478
• stun.twt.it:3478
• stun.uls.co.za:3478
• stun.unseen.is:3478
• stun.usfamily.net:3478
• stun.viva.gr:3478
• stun.vivox.com:3478
• stun.vo.lu:3478
• stun.voicetrading.com:3478
• stun.voip.aebc.com:3478
• stun.voip.blackberry.com:3478
• stun.voip.eutelia.it:3478
• stun.voipblast.com:3478
• stun.voipbuster.com:3478
• stun.voipbusterpro.com:3478
• stun.voipcheap.co.uk:3478
• stun.voipcheap.com:3478
• stun.voipgain.com:3478
• stun.voipgate.com:347
• stun.voipinfocenter.com:3478
• stun.voipplanet.nl:3478
• stun.voippro.com:3478
• stun.voipraider.com:3478
• stun.voipstunt.com:3478
• stun.voipwise.com:3478
• stun.voipzoom.com:3478
• stun.voys.nl:3478
• stun.voztele.com:3478
• stun.webcalldirect.com:3478
• stun.wifirst.net:3478
• stun.xtratelecom.es:3478
• stun.zadarma.com:3478
• stun1.faktortel.com.au:3478
• stun1.l.google.com:19302
• stun2.l.google.com:19302
• stun3.l.google.com:19302
• stun4.l.google.com:19302
• stun.nextcloud.com:443
• relay.webwormhole.io:3478

While there are a number of Public STUN servers available, these may not be a fit for commercial purposes. It is always better to deploy and manage your own STUN server in this case.

See also

• ICE
• NAT and VOIP
• STUN clients: List of SIP Clients (UAs) that support STUN
• STUN-bis
• TURN

Note: XOR_MAPPED_ADDRESS support on STUN Servers

Some home routers (namely Linksys routers whose firmware is based on the Linux kernel) have a tendency to alter the STUN reply packets from the STUN server. It changes the MAPPED_ADDRESS from the public IP address derived by the server to the IP address of the router’s WAN port. If the router’s WAN port is not assigned a public IP address (as in the case of Internet service providers like AT&T Uverse), then the application using STUN to discover its public IP address will get the wrong info.

STUN provides a work-around to this problem via XOR_MAPPED_ADDRESS. A STUN client can request an XOR_MAPPED_ADDRESS as well as the standard MAPPED_ADDRESS. While the router may alter the MAPPED_ADDRESS, it shouldn’t change the XOR_MAPPED_ADDRESS.

Unfortunately, not all STUN servers support XOR_MAPPED_ADDRESS. The public STUN servers listed on this wiki have been updated with info about lack of support for XOR_MAPPED_ADDRESS.

Additional reading

STUN sits alongside a number of techniques to achieving NAT traversal, these include TURN, ICE UPnP and Session Border controllers. ICE provides a framework that pulls together a number of different techniques: STUN, TURN, RSIP, to allow a client to investigate its environment, however, this flexibility comes at a cost – additional client complexity.

• Public IP Service For testing purposes, if you need a fall back method to using STUN, you can refer to this site which provides public ip on your end machine.
• The White Paper on NAT traversal from Newport Networks summarizes the pros and cons of different NAT traversal techniques. White Paper – NAT Traversal for Multimedia over IP Services
• http://www.ietf.org/rfc/rfc5389.txt Detailed information about STUN from the IETF
• Detailed information about STUN from 3CX