1

In these two figures, why the 173.239.151.99(clientB) and the STUN server both know the clientA(192.168.0.1)'s public IP, why clientB can't reach clientA but STUN server can?

Or to put my question this way: why we need STUN server after all? Say when clientA send request to clientB, there will be a binding between clientA's IP&port and NAT device's public IP&port in translation table, this " mapping is created when a TCP SYN packet is sent from inside the NAT or when a first UDP packet is sent.", so when clientB sends response back, the translation table will help it to reach clientA. Then why on earth we need STUN?

figurefigure2

Improve this question

1 Answer 1

Reset to default
2

syntethic task ;-)

STUN can be used only with "full cone NAT, restricted cone NAT, and port restricted cone NAT"… but not with symmetric NAT. STUN is the protocol for clients, but clients, as usually, in real world are using symmetric NAT(unique port for any connection, dynamic translation)! In the real world servers are using full-cone NAT(static translation), and servers, as usually, gets connections from clients, which are already know ip:port…

However, formal answer: most "frequent" using of STUN it is sip client to server keepalive(udp), but there are also other usages: https://www.rfc-editor.org/rfc/rfc5389#section-14:

14.  STUN Usages
   At the time of writing, three STUN usages are defined: Interactive
   Connectivity Establishment (ICE) [MMUSIC-ICE], Client-initiated
   connections for SIP [SIP-OUTBOUND], and NAT Behavior Discovery
   [BEHAVE-NAT].  Other STUN usages may be defined in the future.
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.