I have been reading about WebRTC and how it enables peer to peer communication. So, i did a experiment for NAT traversal.
The experiment objective was to test hole punching in NAT. I had two system both were running Ubuntu 16.04. I will refer to these systems as system A and system B.
Both systems connect to a server hosted on Amazon Web Services. System A used command nc -p 1234 -u IP_ADDRESS_OF_SERVER PORT_NUMBER_OF_SERVER and system B used command nc -p 1235 -u IP_ADDRESS_OF_SERVER PORT_NUMBER_OF_SERVER. System A and system B both were connected to the same WiFi router.
After connecting to the server, we got to know about public socket of both systems. After that, i tried to connect each other using the information of public socket we got from the server within few seconds.
System A disconnects itself from server and connects to system B by using the command nc -u -p 1234 PUBLIC_IP_OF_SYS_B PUBLIC_PORT_OF_SYS_B and system B also disconnects itself from server and connects to system A by using the command nc -u -p 1235 PUBLIC_IP_OF_SYS_A PUBLIC_PORT_OF_SYS_A.
I did this to punch a hole in our NAT. After it, system A cancel the above nc command and listen to it's port using nc -l -u -p 1234. But unfortunately, i wasn't able to receive any message typed in system B in system A.
Can anyone help me in getting this work?
So, i figure it out myself. What i was trying to do is called Hairpin Translation and hairpin translation is still much less common among existing NATs (as compared to hole punch translation).
The two systems happen to reside behind the same NAT, and are therefore located in the same private IP address realm. System A has established a UDP session with server S, to which the common NAT has assigned its own public port number(say x). System B has similarly established a session with S, to which the NAT has assigned public port number (say y).
Suppose that system A uses the hole punching technique to establish a UDP session with B, using server S as an introducer. System A sends S a message requesting a connection to B. S responds to A with B's public and private endpoints, and also forwards A's public and private endpoints to B. Both clients then attempt to send UDP datagrams to each other directly at each of these endpoints. The messages directed to the public endpoints will not reach their destination as our NAT doesn't support hairpin translation.
Anyone can read about hairpin over here.