Categories
Game Development

NAT punch through with symmetric routers

Spent like 8 hours straight today working with a customer on getting NAT punch through working with symmetric routers. The technique I was using with RakNet was essentially STUN, with an early datagram with TTL set to 2. This avoids the problem of one message arriving early, despite attempts to send simultaneously, and ending up […]

Spent like 8 hours straight today working with a customer on getting NAT punch through working with symmetric routers. The technique I was using with RakNet was essentially STUN, with an early datagram with TTL set to 2. This avoids the problem of one message arriving early, despite attempts to send simultaneously, and ending up IP banned on one router.

Very few sites on the internet go farther than STUN. I found this article at newport-networks on other techniques, however none of them were practical. Boiling down the 6 pages to two sentences, the first technique was to route the messages. The second was to have a filter past the router that modified the destination addresses.

I later found a much better paper at cornell.edu. It’s long but gives a good explanation of the problem. To boil it down to one sentence, it says it is impossible to connect peers both behind symmetric NATs in a reliable way, but you can guess the remote port based on typical router implementations.

I use the external port … external port + 4 and the internal port … internal port + 4. It worked for me connecting to the guy I was working with, but not the other way around. However, I suspect he was doing something wrong since it was 3 AM his time and his output didn’t make sense.

Here’s the code

I’m feel exhausted after doing this all day although all I’ve done is sit here in front of the computer.

*** EDIT ***

Came up with the idea to also have the recipient send datagrams to the sender’s possible open ports. If one of those datagrams arrives, the sender will use the external port therein. This ought to halve the failure rate by handling the case where the receiver could have connected to the sender but not vice-versa. Because I can send these datagrams all at once (rather than connecting one attempt at a time), it should help the system complete faster too.

I’m pretty happy about this because I have known for a while my NAT punchthrough wasn’t tested to the degree it should have been. I think it’s pretty robust now. The only thing I’m not doing is uPnP, and maybe I’ll add that further down.

Leave a Reply

Your email address will not be published. Required fields are marked *