UDP hole punching not going through on 3G
I'm trying to implement in a software a hole punching feature. The thing is, I'm implementing this with an already made TCP Server to communicate with Users.
Here's what I have so far :
- "A" sends a message to an UDP Server "US" (on port 9333)
- "US" sends back to "A" the port it has connected to (port 31000 - localport 31005)
- "A" sends a message to a TCP Server "TS" saying he want's to connect to B (and give the port 31000)
- "TS" sends a message to "B" giving him the "A"'s port (31000) and ip
- "B" sends a message to "US" (on port 9333)
- "US" sends a message to "B" telling him his port 45000 (localport 45005)
- "B" sends a message to "TS" giving is udp port (45000)
- "TS" sends a message to "A" giving B's udp port (45000) and ip
- "A" start sending udp message to B's ip on port 45000 and listen on localport 31005
- "B" start sending udp message to A's ip on port 31000 and listen on localport 45005
Of course ports 31000, 31005, 45000 and 45005 are here for example, every new connection the port change, only 9333 is static.
I know there is a lot of back-and-forth, more than it should really be. The fact is I'm bound to use the TCP server to communicate with both users, the udp server is just here to return User's port to himself so it can send it back to TCP Server.
However messages between users are not received by any... Anyone would have an idea why ?
EDIT :
I have tested my router with http://nattest.net.in.tum.de/test.php and udp hole punching works fine, so the issue is not coming from my router, but from my protocol...
When users are behind the same NAT, everything works fine, of course it uses privates ip, but it means that the code is working also, so every though leads to a protocol issue...
EDIT 2 :
Actually, I made it half work (And the problem was coming from my code actually, not the protocol... I have connected 2 users, one in 3G with an iPhone, one behind my NAT on Wifi.
The funny (well not so much) thing is, only one socket were able to receive and send data between both users. (the socket initiated by the iphone) According to the protocol I should have 2 well-connected sockets, am I wrong ?
So I managed to punch a hole in my NAT, but actually not in the cellular NAT.
Of course, I tested right away 2 iphones connected in 3G. And no one get's the message from the other.
Did I missed something about cellular NAT ?
P.S. : Sorry for updating so much my question, but since I get no answer I'm trying to find by myself...
P.S. 2 : Since I managed to punch a hole in my NAT, I have changed the title adding "on 3G"
EDIT 3 : I ran the http://nattest.net.in.tum.de/test.php test again with my computer connected to internet through my iphone's 3G connection.
Here's the result :
Apparently all udp hole punching test were successful on the 9th test.
Further more it seems :
UDP Binding Test (?): Endpoint independent binding, port prediction is easy
So it should not be any trouble connecting 2 peers over 3G Connection (well not much than behind a "home" NAT)... Am I right ?
EDIT 4 :
Just to be sure, I now send a message to two distinct UDP Server, to check if the port and the local port are the same on 3G.
Long story short, ports (local and public) are the same when connecting on both server. so the test done on EDIT 2 was right, udp is endpoint independent, so there should not be any issue doing the hole punching I guess... (At least with my ISP)
Answer
Unfortunately, there is no 100% reliable way to perform NAT hole punching with UDP. At best, you can make some guesses about how NATs and firewalls will probably behave most of the time. But there will always be exceptions and they may not be rare.
In this case, it sounds like you are using a central server to let two peers figure out each-others external port and then start sending data at each other. That's a pretty good algorithm. The problem is that the external port routing may vary depending on the destination. In other words, if A to B has an external port of 5000, there is no guarantee that A to C will also come from 5000. So having a central server record the port it sees may not help to connect anyone else.
Here are a few related questions with some more details.