NAT Punch Through
Author
Hey all, I read about the NAT punch through technique in another thread (from this site), and I have a couple of questions.
Does this work at all? I saw a load of updates at the bottom of the page that made me worry about this a bit.
This seems to only work with TCP. Is there a way to do this with TCP/IP? I know all about the protocol, and why this probably won't work.
Quote:Original post by Evil SteveApparently not if you think there's a difference. :)
This seems to only work with TCP. Is there a way to do this with TCP/IP? I know all about the protocol
This will certainly work for UDP.
For TCP it will work ONLY if the NAT router is naieve. Personally, I'd ditch a NAT box if it didn't look at TCP sequence numbers (insecure), but for optimization reasons, I suppose many wouldn't.
I didn't look closely at the explanation, it was quite long winded.
But the sequence I'd use looks like this:
A connects from port X to port X on B. This connection attempt slams into B's firewall and dies, but opens A's NAT firewall to B X->X. A starts a server on port X. B connects from port X to port X on A. Packet goes through the opening A jsut created, and connects.
Does this work? For simple NAT boxes, yes. For secure ones, no.
I love how the author of that site thinks that the ones it doesn't work on are "broken".
Author
Damn. Thats what I thought. BTW, I just noticed that the author is our very own hplus0603 :P
I'll do some tests with UDP only, but TCP would be preferable. I'm going to be making a IM service, and it makes my life easier if there can be a TCP/IP connection between 2 members of a conversation...
I'll do some tests with UDP only, but TCP would be preferable. I'm going to be making a IM service, and it makes my life easier if there can be a TCP/IP connection between 2 members of a conversation...
I'm willing to bet most of the consumer-level NAT boxes will allow TCP punching.
It's probably worth putting all three code paths in, and when you're negotiating with the chat server, have the clients send what they think the local IP is (see who's NAT'd), and have the server tell the clients who should open a port and who should connect and whether or not punching is necessary.
That'd be pretty sweet, actually.
It's probably worth putting all three code paths in, and when you're negotiating with the chat server, have the clients send what they think the local IP is (see who's NAT'd), and have the server tell the clients who should open a port and who should connect and whether or not punching is necessary.
That'd be pretty sweet, actually.
Author
So how would TCP punching work? I'm assuming I can't use the UDP punch through, then just try connecting on that port, the router will differentiate between TCP and UDP.
The site linked to from the site I mentioned doesn't describe how to perform a punch through with TCP, it just says that it can.
The site linked to from the site I mentioned doesn't describe how to perform a punch through with TCP, it just says that it can.
It works for 95% of all firewalls with UDP. It works for pretty much all "personal" and "cable/DSL" and "access point" firewalls/NATs, but will not work with some corporate NAT firewalls based on BSD (because they will re-allocate a new public port for each connection pair, even if it's sourced from the same inside port).
Even if it's naive, it won't work. TCP allocates a new port for each connetion pair, so even if the NAT re-uses external ports for the same client port, it won't have the same client port, and thus the introducer doesn't have any useful information.
You should look into "paketto" if you want to try doing TCP NAT punch-through. But it's by its very nature something that won't work well (you have to GUESS port numbers, and sometimes even sequence numbers).
Quote:
For TCP it will work ONLY if the NAT router is naieve.
Even if it's naive, it won't work. TCP allocates a new port for each connetion pair, so even if the NAT re-uses external ports for the same client port, it won't have the same client port, and thus the introducer doesn't have any useful information.
You should look into "paketto" if you want to try doing TCP NAT punch-through. But it's by its very nature something that won't work well (you have to GUESS port numbers, and sometimes even sequence numbers).
Author
Great, thanks. I'll probably just stick with a reliable UDP-based system, but allow traffic to be routed through my server for if the punch-through fails. IM traffic won't account for much.
Cheers,
Steve
Cheers,
Steve
Routing through the match-maker when you can't punch through is how most of the systems that care do it. As long as there's no file sharing going between the servers, of course -- that'd be WRONG! :-)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
